Re: bin/47431: nanosleep is more like millisleep

[David Laight <david%l8s.co.uk@localhost>]

The following reply was made to PR bin/47431; it has been noted by GNATS.

From: David Laight <david%l8s.co.uk@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
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 
wrote:
 > >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
 > nanosleep(*).
 
 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
 together).
 
        David
 
 -- 
 David Laight: david%l8s.co.uk@localhost