The dangers of sleeping ...

[Dale Martenson]

------_=_NextPart_001_01C44F3B.B0C3E730
Content-Type: text/plain;
charset="iso-8859-1"

I learned something about Kernel::sleep that disturbs me. Compare these two
ruby programs:

Program #1:

p "Before sleep"
sleep 30
p "After sleep"

Program #2:

p "Before sleep"
a = Thread.new { sleep 30 }
a.join
p "After sleep"

Not very interesting I know, but both programs should print out the first
line, sleep for 30 seconds and then print out the second line. This is true
as long as the system clock is not altered. The first program does not
appear to be effected by modification of the system clock, but the second
program is. The effect seems to be, if the clock is set back X number of
seconds, the sleep is increased by X number of seconds. Setting the clock
forward doesn't seem to have an effect.

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.

What I really need is an elapsed time which is not tied to the system clock.
A simple tick count that can be used for simple timers. I am now looking
into writing a C extension to use Posix sleep (or something equivalent). Has
anyone else run into this?

This was tested with Ruby 1.8.0 running on Linux.

------_=_NextPart_001_01C44F3B.B0C3E730--

 

[Ben Giddings]

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.

See, the thread should more properly be titled 'the dangers of messing
with the clock on a running system'.

Take a look at the NTP RFCs. They go to enormous pains to slew the
clock, rather than stepping it. If you ever move a computer's clock
backward, expect crazy things to happen. Moving it forward suddenly
isn't good, but it isn't nearly as dangerous.

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. If you
essentially 'mess with causality' you should expect things to break.

Ben

 

[Michael Geary]

There's your problem.

See, the thread should more properly be titled 'the dangers of
messing with the clock on a running system'.

Take a look at the NTP RFCs. They go to enormous pains to slew
the clock, rather than stepping it. If you ever move a computer's
clock backward, expect crazy things to happen. Moving it forward
suddenly isn't good, but it isn't nearly as dangerous.

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. If you
essentially 'mess with causality' you should expect things to break.

Ben, do your customers really let you talk to them that way?

I can just picture myself telling a customer, "Don't ever change the system
clock by more than a few seconds when you're running my application. If you
mess with causality like that, you should expect things to break, and it's
really your fault."

Maybe you can get away with it, but I'd be scared to even try! That customer
will run away looking for someone who can write *reliable* code.

If I tell them it's not really a bug, that it only happens because I use
this cool programming language that uses the most portable APIs, they'll
say, "Huh? *Your* program has a bug. Are you going to fix it or not?"

So I figure I'd better see it their way if I want to stay in business...

-Mike