Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!cs.utexas.edu!sun-barr!newstop!grapevine!sun!snafu!lm
From: lm@snafu.Sun.COM (Larry McVoy)
Newsgroups: comp.unix.wizards
Subject: Re: fcntl/socket anomaly
Keywords: obscure behavior
Message-ID: <129970@sun.Eng.Sun.COM>
Date: 8 Jan 90 04:04:05 GMT
References: <10763@encore.Encore.COM>
Sender: news@sun.Eng.Sun.COM
Reply-To: lm@sun.UUCP (Larry McVoy)
Organization: Sun Microsystems, Mountain View
Lines: 32

In article <10763@encore.Encore.COM> peralta@encore.com (Rick Peralta) writes:
>[ode to old bugs...]
>
>Why when setting the F_SETOWN on a socket a pfind is not done on the PID?
>Maybe more to the point, why the double standard on how a pgrp is specified?
>
>
> - Rick

F_SETOWN has been a botch from day one as far as I'm concerned.  For
those who don't know (or don't remember) F_SETOWN is used to say "send
this pid the SIGIO when the time is right".  The documentation has
always said that you can specify pgrps instead of pids (one of them was
negative to indicate the type) and SunOS, at least, never did that
(stay tuned).  Furthermore, the F_SETOWN uses the same field in the tty
structure that the tty sub system uses for job control (where ^Z and
others get sent).  So if you use F_SETOWN on an active tty you get very
strange things happening.

My guess is that the SIGIO interface was a hack that some grad student
needed.  They hacked it in, it works in the obvious cases, it's stuck
around.  It needs a rewack to be clean (I just checked SunOS - we do
absolutely no permissions checks on F_SETOWN on sockets).

If you are thinking of fixing this, beware of this:  Some programs may
depend on the tty pgrp for SIGIO.  In other words, if you split the
field into two (tty pgrp and sigio pgrp), then have the sigio go to the
tty pgrp if the sigio field is not initialized.
---
What I say is my opinion.  I am not paid to speak for Sun, I'm paid to hack.

Larry McVoy, Sun Microsystems     (415) 336-7627       ...!sun!lm or lm@sun.com