valgrind stuff

[Brandon Black]

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