Christos Zoulas wrote:
In article <[email protected]>,
Manuel Bouyer <[email protected]> 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.
Mike
