Re: Sleeping in nanos
Re: Sleeping in nanos
- Subject: Re: Sleeping in nanos
- From: Greg <email@hidden>
- Date: Thu, 8 Feb 2007 12:08:50 -0500
On Feb 8, 2007, at 11:53 AM, Shawn Erickson wrote:
Programmers at that time who defined the API and created the original
man page knew that... so it was obvious that the API was allowing
callers to define a timing request that was in no way possible to
support at the time.
Darn, it's just so obvious. I'm glad car manufacturers don't take
this stance. "Your car will slow down when you press the brake
pedals, except sometimes it might not brake as fast due to system
latencies."
(On linux, the call to nanosleep(1) results in a sleep time that is
two million times longer. On OS X, it is fifty thousand times
longer. Imagine that kind of discrepancy with car brakes!)
Yet they designed it such that it would allow
advancement in hardware and schedulers going forward. The man page
makes it clear that... "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)."
What a useful function! It changes as time goes forward! So if I
write an time-critical application today that uses it, my customers
can expect all sorts of malfunctions as they upgrade their system and
hardware!
"Greg, today we upgraded the system, the good news is that your
program no longer hangs, the bad news is that now it has fired
several missiles at Russia and uh... I don't think we've got much
time left to live."
- 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