Thread misbehavior

Follow Rubyists:

This short demo illustrates some very odd threading behavior in
Ruby 1.6 and 1.8:

---
trap ('INT') {
   puts "Trapped SIGINT:  Critical=#{Thread.critical}"
}

busy1=Thread.new {
   loop {1000000.times {};
   puts "busy loop #1, Critical=#{Thread.critical}"}
}
busy2=Thread.new {
   loop {1000000.times {};
   puts "busy loop #2, Critical=#{Thread.critical}"}
}

sleep 5
Thread.critical=true
Thread.pass  #next scheduled thread becomes critical
   #in general, which thread goes critical will be hard to predict!
   #This is why Thread.pass should reset the Thread.critical flag
   #as Thread.stop does.

puts "Signal just interrupted critical section!!!"
puts "MAIN Thread:  Critical=#{Thread.critical}"
---

Run the demo.
Observe that, after five seconds, only busy loop #2 runs
and that it has become the critical thread even though it
never set Thread.critical!

This is due to the fact that Thread.pass does not clear Thread.critical
before it invoked the thread scheduler.  I believe it should.

Now send the process a SIGKILL (control-C usually does this)
Note that the Thread.critical is cleared and the main thread
resumes.

On the surface, clearing Thread.critical before handling a signal
may seem like a good idea.  However, given this behavior,
I can find no way to write a multi-threaded program in Ruby that
also handles traps safely.  If a trap can interrupt a critical
section, then any data protected by that section is likely corrupt
after the trap.

Please prove me wrong.

If no one can, then would it not be prudent to at least consider the 
patch I submitted on December 28th in ruby-core:4039?

- brent