From: Ben Giddings [mailto:bg-rubytalk@infofiend.com]
Sent: Thursday, June 10, 2004 6:00 PM
Dale Martenson wrote:
> This problem came up as part of a large ruby server
application where an
> operator noticed the time on the server was way off and set
the clock back a
> couple of hours to correct the problem. The system locked
up. Threads using
> the sleep function never woke up.
There's your problem.
...
This doesn't mean this isn't a bug, and it doesn't mean that software
shouldn't be written with the possibility of this happening
in mind, but
it's really the fault of the person running the system.
I guess when I think of sleeping. I don't see the relationship between
sleeping for a particular length of time and what the clock says. This may
be since I work with a lot embedded systems where tick counts are used to
for timing events. Date and time information may or may not be available.
I just thought it was odd that it wasn't accounted for and that its behavior
varied depending on if it was in a thread or not.
···
-----Original Message-----
Dale Martenson <dmartenson@multitech.com> writes:
I guess when I think of sleeping. I don't see the relationship between
sleeping for a particular length of time and what the clock says. This may
be since I work with a lot embedded systems where tick counts are used to
for timing events.
Clearly you've a lot of job security.
Dale Martenson wrote:
I guess when I think of sleeping. I don't see the relationship between
sleeping for a particular length of time and what the clock says. This may
be since I work with a lot embedded systems where tick counts are used to
for timing events. Date and time information may or may not be available.
Right, and there's a vast difference between how things are done on embedded systems and on full-fledged OSes. Especially when it comes to platform-neutral languages like Ruby, they very rarely have access to low-level system services, like real time clocks.
To be portable, Ruby probably uses system services that are at as high a level of abstraction as possible. Since I'm pretty sure there are no platform-independant ways of doing rtc-style timing, I would guess Ruby relies on the system clock.
I just thought it was odd that it wasn't accounted for and that its behavior
varied depending on if it was in a thread or not.
Yeah, I guess it is odd, but I'd consider it a corner case. If you want to look at how sleep is implemented under the hood in Ruby, you're welcome to do it. If you can suggest a better way of doing it, so that it is able to deal with the system clock getting changed by a huge amount, that would be great!
Ben
If you look at sleep(3) you'll find:
DESCRIPTION
The sleep() function suspends execution of the calling process until
either seconds seconds have elapsed or a signal is delivered to the
process and its action is to invoke a signal-catching function or to ter-
minate the process. System activity may lengthen the sleep by an inde-
terminate amount.
(The last sentance is of the most importance.) sleep is implemented this way
in most languages because the OS provides no better guarantee for sleep time.
···
Dale Martenson (dmartenson@multitech.com) wrote:
I guess when I think of sleeping. I don't see the relationship between
sleeping for a particular length of time and what the clock says. This may
be since I work with a lot embedded systems where tick counts are used to
for timing events. Date and time information may or may not be available.
I just thought it was odd that it wasn't accounted for and that its behavior
varied depending on if it was in a thread or not.
--
Eric Hodel - drbrain@segment7.net - http://segment7.net
All messages signed with fingerprint:
FEC2 57F1 D465 EB15 5D6E 7C11 332A 551C 796C 9F04
Would it be possible to run a quick test on a system to see how long it took for a thread to perform a certain operation and then use that to measure elapsed time? Perhaps it would even be possible to periodically adjust this measurement as system load varied. It would probably not be very accurate though.