valgrind stuff

Brandon Black blblack at
Thu Apr 10 01:15:27 CEST 2008

Marc Lehmann wrote:
> 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

More information about the libev mailing list