th = Thread.new{
print "Going to sleep for 5 seconds\n"
sleep(5)
print "Going to sleep for infinity\n"
sleep(0)
print “awake, did someone wake me up?\n”
}
key = STDIN.getc
th.run
···
will give:
Going to sleep for 5 seconds
Going to sleep for infinity
awake, did someone wake me up?
test.rb:9:in `run’: killed thread (ThreadError)
from test.rb:9
(with both 1.8.0-preview and 1.6.8)
from the pickaxe book "…An argument of zero causes sleep to sleep forever. "
Have I seriously misunderstood this or something more evil is at work here?
As far as I can see the thread should not give "awake, did someone wake me up"
until after I’ve pressed a key, but sleep 0 seems to really sleep for 0 seconds
instead of until SIGALRM/run.
I am no expert on Ruby threading so this is just a guess:
When the new thread (th) is created and it encounters the sleep(5) it gets
“descheduled” (may not be the right technical term). Now the main thread is
scheduled to run and waits till you hit the key also blocking the other
thread till then. You hit the key, the main thread continues and calls
th.run which causes th to restart. Try replacing th.run with th.join and see
if the whole thing hangs (not a good thing I admit ;-))
HTH,
– shanko
“Bjorn Stahl” bjst01@student.bth.se wrote in message
news:20030119205500.147094cf.bjst01@student.bth.se…
th = Thread.new{
print “Going to sleep for 5 seconds\n”
sleep(5)
print “Going to sleep for infinity\n”
sleep(0)
print “awake, did someone wake me up?\n”
}
key = STDIN.getc
th.run
will give:
Going to sleep for 5 seconds
Going to sleep for infinity
awake, did someone wake me up?
test.rb:9:in `run’: killed thread (ThreadError)
from test.rb:9
(with both 1.8.0-preview and 1.6.8)
from the pickaxe book "…An argument of zero causes sleep to sleep
forever. "
Have I seriously misunderstood this or something more evil is at work
here?
As far as I can see the thread should not give “awake, did someone wake me
up”
until after I’ve pressed a key, but sleep 0 seems to really sleep for 0
seconds
I am no expert on Ruby threading so this is just a guess:
When the new thread (th) is created and it encounters the sleep(5) it gets
“descheduled” (may not be the right technical term). Now the main thread is
scheduled to run and waits till you hit the key also blocking the other
thread till then. You hit the key, the main thread continues and calls
th.run which causes th to restart. Try replacing th.run with th.join and see
if the whole thing hangs (not a good thing I admit ;-))
HTH,
– shanko
took a little peek at the ruby source, rb_sleep_forever() (the behaviour I was looking for)
was called only if no parameters were supplied (argc == 0) when calling sleep.
This is abit confusing in relation to what “ri sleep” says:
“…An argument of zero causes sleep to sleep forever…”
I interpreted that as using 0 as an argument would make it sleep forever.
(And is forever really a good way of saying it? I’d call it making the thread dormant (heck I’d even like
a seperate method for just that behavior).
took a little peek at the ruby source, rb_sleep_forever() (the behaviour I
was looking for)
was called only if no parameters were supplied (argc == 0) when calling
sleep.
Looks like I was completely off on that one
Need to get into the habit of looking at the ruby source once a while.
This is abit confusing in relation to what “ri sleep” says:
“…An argument of zero causes sleep to sleep forever…”
Yes, it is to me too !
I interpreted that as using 0 as an argument would make it sleep forever.
Exactly … and that was still the interpretation I was carrying. Thanks for
clearing it up.
(And is forever really a good way of saying it? I’d call it making the
thread dormant (heck I’d even like
a seperate method for just that behavior).
You mean an instance method like thread.dormant which will be like the class
method Thread.stop
Hmm…