Re: select/poll bug?

[christos%astron.com@localhost (Christos Zoulas)]

In article <1217683574.3503.13.camel%uberpc.marples.name@localhost>,
Roy Marples  <roy%marples.name@localhost> wrote:
>On Sat, 2008-08-02 at 11:23 +0200, Alan Barrett wrote:
>> On Sat, 02 Aug 2008, Roy Marples wrote:
>> > no man page for select(2) or poll(2) indicate that it *may* return
>> > a timeout even when there's a very small amount of time left to
>> > wait. This amount of time is normally around 500 usecs or less
>> 
>> Are you saying that NetBSD's select(2) and poll(2) do not actually do
>> what they are expected to do?  Please could you explain in more detail,
>> and is there a PR for this?
>
>OK, this is what happens on Linux - I didn't actually test on NetBSD or
>FreeBSD for this specific issue. I will test later today, but am pretty
>sure it exists as Joerg did report a similar issue once but could not
>reproduce it. But, roughly, the issue is like this
>
>struct timeval expire, now, wait;
>get_monotonic(&now);
>timersub(&expire, &now, &wait);
>if (select(...., &wait) == 0) {
>       get_monotonic(&now);
>       if (timercmp(&expire, &now, >))
>               printf("error!\n");
>}
>
>get_monotonic is a clock_gettime call that converts the resultant
>timespec into a timeval.
>
>I did find a discussion on the Linux kernel mailing list about this very
>issue and the end result was don't use select/poll for high resolution
>dependant timers. I'll see if I can dig the link up.

On NetBSD you should use pollts(2) I think.

christos