From: Tomas Pospisek <tpo2@...>
Date: 2007-03-02T01:10:08+09:00
Subject: Re: replacing the use of gettimeofday in the scheduler

Quoting Tomas Pospisek <tpo2@sourcepole.ch>:

> Has there been any effort to implement a [scheduling] solution based on
> sleep/usleep? Is the interest to implement a more robust schedule timing
> mechanism? Is there a chance for a patch based on sleep/usleep to make it
> into CVS?

gnu-libc's sleep(3) manpage suggest that sleep and SIGALRM on non-glibc systems
don't get along. From the POSIX spec [1]:

    "If a SIGALRM signal is generated for the calling process during execution
     of sleep(), except as a result of a prior call to alarm(), and if the
     SIGALRM signal is not being ignored or blocked from delivery, it is
     unspecified whether that signal has any effect other than causing sleep()
     to return."

( Thus it is possible that Ruby's signalhandler for SIGALRM will *not* be
  executed )

Since Ruby *does* allow the user to handle SIGALRM that would mean that an
implementation based on libc-sleep would fail to work correctly on the above
described systems, that don't handle SIGALRM together with sleep gracefully,
when the user is doing stuff with SIGALRM.

Does anybody know how relevant that is? I.e. does Ruby run at all on such
systems? The above would seem to exclude to implement scheduler waiting with
libc-sleep since that would prevent correct functioning of Ruby on such systems
in "corner cases".

?
*t

[1] http://www.opengroup.org/onlinepubs/009695399/functions/sleep.html


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.