Re: A possible bug with non-blocking sockets and SIGIO

[der Mouse <mouse%Rodents-Montreal.ORG@localhost>]

> So I think it would be correct behavior for a process to set O_ASYNC
> and F_SETOWN for an accepted socket explicitly, i.e. the process
> should not count on the accepted socket's origins and flags
> inheritance.  In this case my patch does not break the semantics.

This is true.  The case in which your patch does break things is the
case of code - presumably written to the traditional model, in which
the child socket is not set O_ASYNC even if the parent was - that sets
the parent socket O_ASYNC but expects the child socket to not generate
SIGIO.

I do not actually know whether any such code exists in the wild, but,
given the extreme variety of code that is known to exist, I would be
somewhat surprised if none did.

> I have modified onc.c a bit - now it does not set owner PID for an
> accepted socket. In the logs I see that a server's PID matches the
> value obtained by F_GETOWN for this socket, i.e. the relevant process
> group setting was copied, isn't it?

That would be my inference too: apparently the F_SETOWN-set owner is
getting copied as well.

It might be interesting to try using
fcntl(fd,F_SETFL,fcntl(fd,F_GETFL,0)|O_ASYNC) unconditionally, rather
than doing so only if O_ASYNC is clear in the F_GETFL-returned flags.
While it is in no sense a fix for the problem, if that leads to the
socket being set async as well, it might be a usable workaround for the
short term.

/~\ The ASCII                             Mouse
\ / Ribbon Campaign
 X  Against HTML                mouse%rodents-montreal.org@localhost
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B