Re: Sleeping in nanos
Re: Sleeping in nanos
- Subject: Re: Sleeping in nanos
- From: Michael Smith <email@hidden>
- Date: Wed, 7 Feb 2007 23:04:58 -0800
On Feb 7, 2007, at 3:07 PM, Greg wrote:
On Feb 7, 2007, at 4:23 PM, Michael Smith wrote:
You should not check rmtp unless nanosleep returns -1 and errno is
EINTR. The manpage is quite specific about this.
The man page does not say it in those terms, it implies that by
sticking two sentences next to each other, it could definitely have
been more explicit.
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.
The choice of nanoseconds permits an application to provide more
detail about its requirements. 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.
There are plenty of situations where, even on modern hardware,
nanosleep might delay execution for less than 1µs.
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".
When the function does not return in error and set the rmtp
variable accordingly, this only serves to further confuse the
developer.
If the developer had read and inwardly digested the manpage, the
behaviour of nanosleep (which is both logical and functional) would
not be confusing.
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.
When his application must run on multiple systems, it does not help
that the function behaves completely different and does not provide
an adequate explanation for the discrepancy.
I believe at this point you're trying very hard to make what was a
relatively harmless mistake on your part entirely someone else's fault.
It would have been nice had there been a more descriptive note
about this in the man pages of either system (beyond what's
already in there).
Manpages generally assume a level of basic understanding of
systems programming philosophy; attempting to explain these
principles in every manpage (would you want to see the same two or
three hundred pages appended to each one?) would be prohibitive.
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.
= 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