Re: pipe read returning EAGAIN

[christos%astron.com@localhost (Christos Zoulas)]

In article <20160208104744.GA11991%asim.lip6.fr@localhost>,
Manuel Bouyer  <bouyer%antioche.eu.org@localhost> wrote:

>There is a call to pool. What happens is that it gets a POLLIN event
>for both fd 3 (which really has data to read) and fd 4 (wich doesn't).
>
>The read callback for fd 4 expects to be called only when there's really
>data to be read, and if read returns EAGAIN it loops until it gets data.
>
>poll is called with a set of descriptors, and returns that there is 1
>descriptor ready to be read. But the POLLIN flag is set for both 
>descriptors 3 and 4.
>
>Now the question is why is the POLLIN flag set when there's no data to read ?
>zeroing out revents before callin poll(2) doens't help.
>
>The man page says:
>     This implementation differs from the historical one in that a given file
>     descriptor may not cause poll() to return with an error.  In cases where
>     this would have happened in the historical implementation (e.g. trying to
>     poll a revoke(2)d descriptor), this implementation instead copies the
>     events bitmask to the revents bitmask.  Attempting to perform I/O on this
>     descriptor will then return an error.  This behaviour is believed to be
>     more useful.
>
>Does it do so if the file descriptor's error is EAGAIN ?
>If so that's no very usefull ...

I don't think it does. If the file descriptor is revoked I believe it
returns EIO. The question is that if the read code sees an error (EAGAIN),
why does it retry? Is it because it expects to get a "full message" and it
does not? Does it get any bytes?

christos