[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: kern/47431: nanosleep is more like millisleep
The following reply was made to PR kern/47431; it has been noted by GNATS.
From: mlelstv%serpens.de@localhost (Michael van Elst)
Subject: Re: kern/47431: nanosleep is more like millisleep
Date: Fri, 11 Jan 2013 10:04:37 +0000 (UTC)
dholland-bugs%NetBSD.org@localhost (David Holland) writes:
> > 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.
> That is very much not useful.
> > Don't think nanosleep can be expected to busy-wait.
> Again, that's the whole point of nanosleep.
The point of nanosleep is to provide a sleep function to which you
can specify the sleep interval with a high resolution. But you
will always get the resolution that is provided by the system
modulo whatever the scheduler will allow.
nanosleep may or may not use a delay loop (it shouldn't except
for tiny intervals). Even then you will hardly get nanosecond
resolution but whatever some hardware timer offers.
> Nonsense. Delay loops delay exactly as long as you want. Because
> NetBSD's nanosleep is defective
The single problem is that the resolution of the NetBSD timer isn't
fine enough for your (and many other) applications.
To fix this you need to implement a high resolution timer (might be
even done tickless), then nanosleep can use this instead of hardclock().
The two remaining problems with this is that maybe not all platforms
have a usuable high resolution timer and that even then the timer might
be too coarse. But on most systems you should get a resolution of
less than 100 microseconds, that's more than 100 times better than now.
Michael van Elst
"A potential Snark may lurk in every tree."
Main Index |
Thread Index |