[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: bin/47431: nanosleep is more like millisleep
The following reply was made to PR bin/47431; it has been noted by GNATS.
From: David Laight <david%l8s.co.uk@localhost>
Subject: Re: bin/47431: nanosleep is more like millisleep
Date: Fri, 11 Jan 2013 08:36:14 +0000
On Thu, Jan 10, 2013 at 11:25:00PM +0000, dholland%eecs.harvard.edu@localhost
> >Number: 47431
> >Category: bin
> >Synopsis: nanosleep is more like millisleep
> nanosleep(2) (and its related forms) do an exceptionally poor job.
> While NetBSD is not a realtime system and nothing is particularly
> guaranteed, the current nanosleep behavior is near-useless and we can
> and should better.
> - (I thought x86 had changed to HZ=1000 some time back, but
> apparently not.)
No - no one has ever changed the default.
> - For all time values >= 20 ms, the resulting delay is nearly
> always the requested time plus 9.99 ms, or sometimes a bit more
> than that. That is, even if the requested delay is an integer
> number of scheduler quanta, we always sleep for one more.
The standard will just say that the time sleeping must be 'at least as
long as that requested'.
So if a program does sleeps in a loop for an interval that is a multiple
of the timer tick they will always be one tick longer than requested.
> Ostensibly if one wants to sleep for small amounts of time, one is
> supposed to busy-loop; this is fine. However, nanosleep is supposed to
> do this for me, and do it in the kernel where ready access to
> fine-grained timing is available. This is arguably the whole point of
Don't think nanosleep can be expected to busy-wait.
In any case, very short busy-waits don't have the desired effect
(they are either much longer than wanted, or you are trying to separate
bus cycles and delays in bridges (etc) mean the cycles can get moved
David Laight: david%l8s.co.uk@localhost
Main Index |
Thread Index |