Fwd: Sleeping in nanos
Fwd: Sleeping in nanos
- Subject: Fwd: Sleeping in nanos
- From: "Shawn Erickson" <email@hidden>
- Date: Thu, 8 Feb 2007 08:53:03 -0800
oops missed copying the list...
On 2/7/07, Greg <email@hidden> wrote:
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.
When reading man pages about API it help note the date of when the API
first appeared.
In the case of nanosleep it states it conforms to what was defined in
1993. In 1993 we did not have CPUs that could service a single
instruction in anyway close to one nanosecond. Even today we are just
starting to pass that threshold (not passed it far enough to even
approach the 1000s of instructions likely needed for true thread
sleep).
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. 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)."
So seeing that I would feel the need to investigate what latencies you
can expect and what timer resolution of the hardware/schedular you
could expect.
-Shawn
_______________________________________________
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