From: Avdi Grimm <avdi@...>
Date: 2007-03-02T00:12:23+09:00
Subject: Re: replacing the use of gettimeofday in the scheduler

On 3/1/07, Tomas Pospisek <tpo2@sourcepole.ch> wrote:
> However, this applies in exactly the same way to libc-select as well and thus
> replacing the select/gettimeofday mechanism by libc-sleep should at least work
> no worse. Objections?

My first reaction was:  good god, the scheduler uses wallclock time?!
Speaking as someone who works on realtime systems (and thus has to
think about scheduler implementation often), this is never a good
idea.  I don't know the background for Ruby's scheduler design, but
normally I'd regard a scheduler which uses wallclock time as just
plain *broken*.  I'm heartily in favor of changing it to something
which isn't dependent on the clock.

That "indeterminate amount" referenced above is simply the price you
pay for running in userspace ion a modern multitasking OS.  Yes,
system activity could delay the return.  That's what multitasking
means: you don't get to choose when you get the CPU.  In practice, if
applications are experiencing unacceptable latency in OS scheduling
then 1) your gettimeofday()-based implementation is going to be
delayed right along with everything else; and 2) you have bigger
problems, because your system is overloaded.

Cheers,

--
Avdi