On Apr 30,  9:53pm, khendricks@ivey.uwo.ca (Kevin B.Hendricks) wrote:
-- Subject: Re: pipes from FreeBSD and the NetBSD async I/O bug

| If you remember, we are not talking about SIGIO on sockets, we are talking 
| about SIGIOs on a pipe whose write end was set for async io and read from the 
| other end is performed.  Such pipes are often used to synchronize between 
| differnt threads and between parent and children.

BSD has traditionally used a pair of sockets to implement pipe(2). For
efficiency reasons, most BSD implementations have since switched to use
specialized code and NetBSD will do so in the very near future.

| This is the behavior in question and NetBSD is the ONLY one that generates 
| this sigio behavior with pipes.  By the way, we do then use poll and find out 
| that fd wants io, unfortunately, no one is waiting to do that io since the 
| write NEVER returned EAGAIN and we were finished with that pipe.   Thus no 
| thread is waiting to be awoken to read from that fd anymore.

I understand. Is it difficult to handle the case where there are no descriptors
waiting for IO, and you get a SIGIO signal? I am not sure what the correct
semantics are here, but since there was a read after the write, in a contrived
scenario, where you wrote exactly the number of bytes that would fit in the
pipe and then read one byte you should get SIGIO because now you should be
able to write one byte.

| Given the above, I don't think the jdk is incorrectly written in this case at 
| all.  As Emmanuel states, this behaiviour under sockets pairs is debatable 
| and obviously not portable but we are talking about how you implement pipe 
| here and not sockets.

Yes, I am not claiming that the NetBSD behavior is correct. I am just stating
that depending on the exact sequences of SIGIO's might make the code less
portable than it would be otherwise. Again, I have not read the jdk code, so
I don't know how difficult it would be to make the code work in both scenarios,
but I think it would be desirable.

christos