From: Shri Borde <Shri.Borde@...>
Date: 2009-01-17T05:03:52+09:00
Subject: [ruby-core:21384] Re: Supporting Thread.critical=with native threads

OK. I understand that MRI cannot make breaking changes lightly (though I do think the API is hard to use the way it is currently speced). We will treat this as an incompatibility in IronRuby and deal with it the best we can.


FWIW, Thread.pass and Kernel#sleep do not set Thread.critical to false. However, they do cause other threads to be scheduled. See this code snippet which I tried with MRI 1.8.6 on Windows Vista.

t = Thread.new do
  Thread.critical = true
  $after_critical = true
  Thread.pass
  $after_critical = true
  Thread.critical = false
end

puts $after_critical # prints true
Thread.pass
puts Thread.critical # prints false

So in your scenario, when you hit a breakpoint, if you call some utility code that happens to do Thread.pass, it will "restart the world" which you will not be expecting.

Also, if you create a new thread expecting no one to see its uninitialized state, I think this is fragile design that will be prone to bugs. If any shared data is accessed from two threads, it should be done only if the threads have set Thread.critical=true (ie. use Thread.critical as a mutex without relying on descheduling of other threads).

I would be curious to see real-world patterns where shared data is accessed safely from two threads, and which relied on descheduling of other threads - to see if it was indeed done safely. (I don't mean to suggest that your particular code has bugs but ...) I think many people who try to use this pattern will end up with latent bugs, and I would like to see if this is the case or not.

Thanks for all the information.

Regards,
Shri