fcntl/socket anomaly

[Chris Torek]

In article <129979 at sun.Eng.Sun.COM> lm at snafu.Sun.COM (Larry McVoy) writes:
>Those checks [applied by TIOCSPGRP] are inappropriate for the F_SETOWN.
>For example, POSIX insists that the tty in question be your controlling tty.
>That's both unecessary and unlikely for processes wanting SIGIO on a tty.

Ah: this is different from what you said (or at least, what I understood)
before.  Now you seem to mean `any process should be allowed to ask for
SIGIO on any file descriptor to which it can apply an fcntl, and should
receive SIGIO signals whenever it could read from / write to that descriptor.'

(This is a reasonable interpretation of what SIGIO should be, but would
require major kernel restructuring, since per-file-descriptor flags can
only be stored in a u. area.)

>Suppose I have process A and process B.  A does a F_SETOWN on some
>socket and then goes on, expecting a SIGIO at some later time.  B comes
>along, and also does a F_SETOWN on the same socket.  A has been
>robbed.

Ah.  This, of course, is a property of the shared-ness of descriptors.
A dup()ed descriptor (either with the dup() or dup2() system calls,
or simply shared across fork+exec) has only one underlying object,
and (for reasons having to do with the basic kernel structure) signals
have to refer to the underlying object%, hence are shared.

Fortunately, two different endpoints on a socket are not shared.  A
program (your `A') that passes its own socket endpoint to another program
(your `B') has explicitly---well, okay, implicitly---given control of
the socket to the second program.  For instance, `B' could issue a
shutdown on the socket as well.

Thus, I think this objection does not apply.  (It *does* apply to tty
devices.)

-----
% Actually, they refer to the object underlying the underlying object,
  in the case of inodes; but this, at least, could be changed in
  principle.  (Thread a linked list of signal info through the file
  table.)  Then you have the problem of *giving up* SIGIO signals for
  a descriptor.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris at cs.umd.edu	Path:	uunet!mimsy!chris