Subject: Re: pipes from FreeBSD and the NetBSD async I/O bug
To: Christos Zoulas <christos@zoulas.com>
From: Kevin B.Hendricks <khendricks@ivey.uwo.ca>
List: tech-kern
Date: 04/30/2001 23:16:49
Hi,

> 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.

I am confused.  I have never seen async io used alone, only with non-blocking 
flag also set does it make sense.  IMHO You should not send a sigio to a 
process that asked to write n bytes to an fd when set up for non-blocking 
asynchronous io unless unless the write returned an error with errno set to 
EAGAIN.

The sequence I expect under async and nonblocking write roughly looks 
something like this:

   n = total number of bytes remaining to write
   here:
   c = attempted write of n bytes
   if c > 0 then n = n -c;  goto here
   if (c = -1 and errno = EAGAIN) then go do something else until sigio
           comes in indicating you are ready to write again

With async and nonblocking I do not expect to get a sigio every time 
something is read from the pipe unless the pipe is full causing the last 
write to return with EAGAIN.

The example is question sets both non-blocking and fasync flags.

Here is what a man page says write should return when non-blocking io is set.

  EAGAIN Non-blocking I/O has been selected using O_NONBLOCK
              and  there  was  no room in the pipe or socket con<AD>
              nected to fd to write the data immediately.

> 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.

In general, I agree but implementing green_threads (user-based) threads is 
hard enough without making some assumptions about what generally works or not.
We made the assumption I roughly laid out above for write 

Kevin