Hi,

> Code written correctly can handle both cases. Making assumptions about
> when SIGIO is going to be sent will just lead to trouble. Typically
> SIGIO is used in conjuction with select/poll to discover if the event
> is a read or write availability event. I really don't understand why
> the jdk is written in a way that fails when it receives extra SIGIO's.

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.

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.

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.

Kevin Hendricks
Blackdown Porting Team for PPC Linux