Re: Sleeping in nanos
Re: Sleeping in nanos
- Subject: Re: Sleeping in nanos
- From: Greg <email@hidden>
- Date: Thu, 8 Feb 2007 11:47:18 -0500
On Feb 8, 2007, at 2:04 AM, Michael Smith wrote:
RETURN VALUES
If nanosleep() returns because the requested time has elapsed,
the value returned will be zero.
If nanosleep() returns due to the delivery of a signal, the
value returned will be the -1, and
the global variable errno will be set to indicate the
interruption. If rmtp is non-NULL, the
timespec structure it references is updated to contain the
unslept amount (the request time
minus the time actually slept).
Like most of the BSD manpages, this one is carefully written and
formatted. The meaning of the above is quite unambiguous.
That nanosleep will return fill the rmtp structure with data only
when it returns -1 is implied right there, as I said, by sticking two
sentences next to each other in the same paragraph. What if they had
been in separate paragraphs? Well, in that case you would probably
say that rmtp would always be filled if not NULL. Thank you for
pointing this out, in the future I will keep this in mind when
reading man pages. Back to the main point of discussion...
Now that is bad programming philosophy. When a developer calls a
function that claims it will sleep in nanoseconds, the programmer
expects it to do just that unless it says otherwise.
Perhaps I should quote the preceding paragraph from the manpage?
DESCRIPTION
The nanosleep() function causes the calling thread to sleep
for the amount of time specified in
rqtp (the actual time slept may be longer, due to system
latencies and possible limitations in
the timer resolution of the hardware).
I believe that it quite clearly states "otherwise".
Now at this point I'm starting to think you're pulling my strings...
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.
2) Nanosleep says it *may* not sleep in nanoseconds due to "system
latencies".
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.
Therefore:
1) Nanosleep cannot sleep for a shorter amount of time than usleep
2) Nanosleep is useless and its man page is severely flawed.
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.
Greg: "Hey Michael, why doesn't your suspendThread() function
suspend the thread?"
Michael: "How can I possibly suspend your thread?? That's impossible!"
Greg: "But your function says—"
Michael: "What are you, some sort of blithering fool???
Clearly you don't understand the intricacies of my genius system!!"
You are correct when you say that man pages are not designed to
teach programming philosophy, they are designed to document the
behavior some some particular function or command. The man page
on nanosleep does not do that. I'm not asking for "hundreds of
pages", a sentence or two would have sufficed for this.
Which "this" did you have in mind? You want an explanation, yet
you haven't actually suggested what you want explained; everything
so far that I can see you griping about is succinctly covered in
the two paragraphs I pasted above.
If you want a justification, rather than an explanation, then no
"sentence or two" is going to touch the subject.
Man page on nanosleep, Greg's version:
nanosleep - suspend thread execution for an interval measured in
nanoseconds
Nanosleep() causes the calling thread to sleep for a duration of
time. This function
is not recommended because on most systems, including OS X, the
nanosleep function
will not sleep for less than 1000 nanoseconds due to system
requirements, it is therefore
not recommended for time critical applications; use usleep instead.
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?
- Greg
_______________________________________________
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