Re: [9fans] sleep(2) historical question

[erik quanstrom <quanstro@quanstro.net>]

On Wed Nov 28 08:11:43 EST 2012, charles.forsyth@gmail.com wrote:
> No, really, I'm quite serious. A grep of /sys/src/cmd/ suggests that
> most sleeps are relatively large, and arbitrary.
> None of the applications look likely to need microsecond let alone
> nanosecond resolution, and that seems reasonable to me.
> One exception is sleep(0), but that's yield()

you haven't explained how one can emulate a sub-ms
sleep with the edf scheduler.  i've got a legit problem.

and i don't see why the common case has anything to do
with this.  if you would look at some of the stuff we're doing
at coraid (which has actually been written this decade),
i think you'll find a number of short sleeps.  i've mentioned
before that doing realistic timeouts for aoe in userspace
would require about a 50-100µs sleep, as rtt on 10gbe
is in the neighborhood of 10-40µs.

under the covers, sleep multiplies ms * 1000000 to get ns,
and sets a timer.  it is a trivial thing that doesn't harm
any part of the system to allow one to specifiy ns directly.
this is a 100% artificial limit to resolution.

also, resolution != precision.  and clearly with the type
of hardware we've got, 1µs is going to be about the limit,
and 10µs is going to be the practical limit.  

in 1990 with 20Mhz processors, one couldn't sleep for 1ms,
probablly not even 10ms.

why do extra zeros on the right bother you?  i don't mind them since
the resolution of the interface is an absolute limit on how
short a sleep i can have.  we could if you want specify sleep
in 10µs units, which would accurately reflect todays hardware.
but i'd rather err on the side of too many zeros on the right
than the left.

- erik