http://www.ruby-doc.org/core/classes/Thread.html#M000461 says:

When set to true, prohibits scheduling of any existing thread. Does not blo=
ck new threads from being created and run. Certain thread operations (such =
as stopping or killing a thread, sleeping in the current thread, and raisin=
g an exception) may cause a thread to be scheduled even when in a critical =
section.

So new threads can be scheduled, as in your example. However, my question i=
s mainly about existing threads. With native threads, it is very hard to pu=
t to sleep existing threads. What will the impact to apps be if they go to =
sleep only if and when they call Thread.critical=3D ? Will this satisfy the=
 spec?

-----Original Message-----
From: Eric Hodel [mailto:drbrain / segment7.net]
Sent: Tuesday, December 30, 2008 5:20 PM
To: ruby-core / ruby-lang.org
Subject: [ruby-core:21002] Re: Supporting Thread.critical=3Dwith native thr=
eads

On Dec 30, 2008, at 15:00 PM, Shri Borde wrote:
> Thread.critical=3D is supposed to not schedule any other thread, in
> addition to guaranteeing that only one thread is ever in the block
> with Thread.critical=3D=3Dtrue. This is easier to support with green
> threads.

This is not true, Thread.critical=3D does not automatically schedule
other threads.  The programmer can schedule other threads as they
desire, however:

$ cat thr.rb
Thread.critical =3D true

t2 =3D Thread.start { puts "in other thread" }

puts "t2 finished: #{t2.inspect}"
$ ruby thr.rb
in other thread
t2 finished: #<Thread:0x29324 dead>