Marc Lehmann wrote:
http://lists.freedesktop.org/archives/dbus/2006-September/005724.html
In case anyone wonders, quoting from gnu/linux manpages is a very bad
idea, they are often very wrong and in contradiciton to both reality and
the unix specification.
The unix specification says:
In each pollfd structure, poll() clears the revents member except that
where the application requested a report on a condition by setting one
of the bits of events listed above, poll() sets the corresponding bit
in revents if the requested condition is true.
If none of the defined events have occurred on any selected file
descriptor, poll() waits at least timeout milliseconds for an event to
occur on any of the selected file descriptors.
Without contradiction, revents *is* cleared by any successful call to poll.
Upon successful completion, poll() returns a non-negative value.
A return value of 0 is non-negative, and therefore the call was successful.
Again, one should report this as a bug in valgrind, flagging correct
programs is a bug in valgrind, and nothing else.
And so far, I have seen zero evidence for this beign a problem in
practise, although I admit I haven't tested this very widely. However,
even if real systems do not implement poll like above, this is likely a
bug in those systems as well (as usually they follow sus), and should be
reported.
I am strictly against implementing kludges on top of bugs instead of
fixing them, whenever possible.
Regardless, if poll() returns zero there's no point in examining revents
anyways right? That makes the whole issue moot. If anything you gain
some performance by not scanning the poll_fd's in the case of a timeout
with no events occuring.
-- Brandon
_______________________________________________
libev mailing list
libev@lists.schmorp.de
http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
