Re: Sleeping in nanos
Re: Sleeping in nanos
- Subject: Re: Sleeping in nanos
- From: Jan Brittenson <email@hidden>
- Date: Thu, 08 Feb 2007 13:26:23 -0800
Greg wrote:
One has to wonder then, why provide such a function to developers
and claim that it *can* possibly sleep for the amount of time requested?
The purpose of nanosleep as defined by the realtime extension of POSIX
1.1-1990 is
to address shortcomings of usleep. The two issues are 1) reliance on
signals (typically
SIGALRM) or other limited resources making usleep unreentrant and non-thread
safe, and 2) some tweaks to the call interface to indicate whether it
was aborted by
a signal or ran to completion. (usleep returns the remaining time but
doesn't
indicate why when it returns early.) The purpose of nanosleep is *not*
to improve the
timing, but to standardize and clean up the behavior of usleep.
An implementation can suspend the calling lwp for larger sleeps; for
shorter sleeps
an implementation can busywait on the cycle counter or some such. But
the caller
could still get preempted, or a device driver locks out interrupts for
some period -- there's
no guarantee that can be made other than if it returns early nanosleep
will let you know
why. There's also so much jitter in the user code execution of any
modern system that
my guess is shorter sleeps than 1 usec would be so unreliable as to be
pointless.
_______________________________________________
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