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? christos
