Current-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: pipe read returning EAGAIN

Christos Zoulas wrote:
In article <>,
Manuel Bouyer  <> 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?

I think in the case of nagios yes it does (incorrectly). I ran into this a while back and its fixed in the nagios head so I was waiting for the package to update before I checked again.


Home | Main Index | Thread Index | Old Index