On Tue, May 22, 2018 at 4:02 PM, <s_g...@telus.net> wrote: > There seem to be two issues with nanosleep. > > The first is a lack of information in the man page. It would be useful to > know that the minimum sleep time is limited to one tick of the system clock > and that it varies with the architecture. >
A reference to clock_getres(2) would make sense, sure. > Second, given the above, there seems to be an initialization or end point > count problem. The minimum time seems to be two ticks, not one and the > sleep time is one more tick than is requested. > nanosleep(2) MUST NOT return before the requested time has passed. Given that hard requirement from POSIX and assuming that it's operating purely in terms of ticks, how can it meet the requirement when the call might come a nanosecond before the next tick? If I request any non-zero amount of time then the kernel can't just wait until the next tick because that may be *too soon*, so under the limitation of only thinking in ticks, it must round up and then add one. Now, if you can work up a diff that peeks at the timecounters and can deduce that it doesn't need to add one because how far away the next tick is, go for it. "I want nanosleep to sometimes lie" is not an option Philip Guenther
