Re: Sleeping in nanos
Re: Sleeping in nanos
- Subject: Re: Sleeping in nanos
- From: Michael Smith <email@hidden>
- Date: Thu, 8 Feb 2007 13:11:25 -0800
On Feb 8, 2007, at 8:47 AM, Greg wrote:
On Feb 8, 2007, at 2:04 AM, Michael Smith wrote:
Let me try to remind you what nanosleep says it will do:
nanosleep -- suspend thread execution for an interval measured in
nanoseconds
Let's go over the facts again:
1) Nanosleep says it will sleep in nanoseconds.
Ok, stop right there.
The nanosleep manpage does not say "it will sleep in nanoseconds".
It says, as you just quoted above, that it will suspend thread
execution for an interval measured in nanoseconds.
2) Nanosleep says it *may* not sleep in nanoseconds due to "system
latencies".
No, the manpage says that thread execution may be suspended for a
period longer than specified. The period that you specify is still
measured in nanoseconds.
3) On OS X and Linux, right now (and most likely in the distant
future), nanosleep will *NEVER* sleep for less than 1000 nanoseconds.
4) This fact (3), is not mentioned anywhere in the man page.
That's because it's not a fact.
Therefore:
1) Nanosleep cannot sleep for a shorter amount of time than usleep
Incorrect. The specification permits an implementation to sleep for
a period both less than a microsecond, and for a period greater than
a microsecond but with sub-microsecond resolution.
2) Nanosleep is useless and its man page is severely flawed.
Laughably incorrect.
In time-critical applications, which is most likely the case when
using a function like nanosleep, the developer expects
predictable behavior that is well documented.
An experienced developer knows that in a conventional
multiprogramming system such as Mac OS X, no guarantees of
predictability are offered.
As a bonus to developers, and reflecting the conflicting demands
placed on the system, Mac OS X offers a number of degrees of "best
endeavours" regarding scheduling latency and priority. At no
point is anything "guaranteed"; the presence of third-party code
and workloads in the system makes such a thing intrinsically
impossible.
It would be interesting to work with you on a software development
project.
It would likely be a very brief experience.
In the common case where code lives well beyond the environment in
which it was originally written this information may allow a
future runtime environment to do a better job.
This is absolutely ridiculous. Have you ever actually written
software that does not work, but you still release it because you
suspect that it might work at some point in the distant future?
Yes. In the business this is called "forwards compatibility", and
anyone with half a brain designing long-lived interfaces and software
components spends a nontrivial amount of time thinking about it. I
do try to go for better than "suspect" though; I prefer "anticipate"
or even "plan".
The nanosleep interface was devised and standardised when it became
clear that systems would, in the reasonable future, have both the
capability and the reasonable desire to suspend execution for periods
shorter than a microsecond. Your ability to parse the manpage or the
preceding sentence notwithstanding, the interface exists, behaves as
it does, and is used for perfectly good reasons, and it would
undoubtedly be to your benefit to understand both those specific
reasons and the environment which justifies them.
= Mike
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden