On Tue, May 01, 2001 at 12:54:06AM +0200, Emmanuel Dreyfus wrote:

 > Do send SIGIO on any read when the write end is set as async (the test
 > says it failed): NetBSD-current, OpenBSD-2.6, FreeBSD-3.4, Digital
 > UNIX-4.0, 

Because the socket implementations in all of those systems is derived
from the same BSD code base.  I suspect IRIX, Ultrix, and SunOS 4 will
exhibit the same behavior as well (since they are BSD sockets inside,
not TLI).

 > Do no send SIGIO (the program says it succeds): Solaris-2.6, Linux-2.2.x
 > It would be interesting to test on other OSes.

These systems have socket implementations *not* derived from BSD.  Solaris's
is a wrapper around TLI.  Linux's was written from scratch.

 > I think this would mean adding a boolean to sowakeup() to enable or
 > disable the SIGIO. And the sowwakeup in usrreq (case PRU_RCVD) could
 > disable the SIGIO depending on the socket flag. I can try implementing
 > this if onbody has something against it.

Adding a flag to the socket structure, set one way or the other depending
on which emulation opened the socket is probably okay to start, but need
to think about what happens when passing the file to another process via
exec, etc.

 > And the last question is what behavor should be used for NetBSD native
 > binaries? I beleive the answer to that question is to keep to the
 > standard behavior, but I don't know what the standard says. Someone has
 > POSIX specs on his desktop?

The problem is that SIGIO is not specified by POSIX or SUSv2.  Therefore,
there is no standardized behavior to follow.  Considering that SIGIO
originated in BSD, it seems as if the behavior we currently have is
"correct", in that it is the behavior of the original sockets implementation.

 > Another note: Digital UNIX 4.0 fails on the pipe test. I've found
 > another OS that does pipe async I/O the same way we do it.

Right, that's because Digital UNIX (which, BTW, is largely "Mach, plus
a bunch of 4.4BSD, plus some SVR4 stuff") uses sockets to implement pipes.

-- 
        -- Jason R. Thorpe <thorpej@zembu.com>