kern/46036: inaccurate timeouts in select(),nanosleep() + fix
Bruce Evans
brde at optusnet.com.au
Fri Nov 16 11:33:31 PST 2007
On Fri, 16 Nov 2007 kmacy at freebsd.org wrote:
> Synopsis: inaccurate timeouts in select(),nanosleep() + fix
>
> State-Changed-From-To: open->feedback
> State-Changed-By: kmacy
> State-Changed-When: Fri Nov 16 07:03:16 UTC 2007
> State-Changed-Why:
>
> Please comment on whether or not this is in fact a bug and then throw back in to the pool.
> Thanks.
There are a lot of different, tiny bugs in this area. I still think that
the behaviour of select() is correct -- select() must sleep for at least
the specified time, and if it only returns for timeouts then it is in
sync with the timeout clock so it must sleep for almost a full extra tick
on the next call to ensure sleeping for long enough. In some other cases
and syscalls, the extra tick can be avoided by waking up 1 tick earlier
and checking if the timeout has expired and going back to sleep if it has
not. The PR followup has details of the other cases. I don't have time
to check these now or plans to work on them. I would mark the PR as
suspended.
This behaviour makes select() unsuitable for implementing a periodic
timeout. If you want a periodic timeout, then use setitimer(2). I
did this for netstat(1) and have thought of doing it in ping(8).
THe problem is smaller with HZ = 1000, but I use HZ = 100.
> Responsible-Changed-From-To: freebsd-bugs->bde
> Responsible-Changed-By: kmacy
> Responsible-Changed-When: Fri Nov 16 07:03:16 UTC 2007
> Responsible-Changed-Why:
>
> Please comment on whether or not this is in fact a bug and then throw back in to the pool.
> Thanks.
Gnats sent 2 copies of the message (one for each change of From-To). In
some other recent gnats mail, gnats seems to just not send 1 of 2 different
messages.
Bruce
More information about the freebsd-bugs
mailing list