kern/46036: inaccurate timeouts in select(),nanosleep() + fix

[Bruce Evans]

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