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 trea=
t 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. How=
ever, they do cause other threads to be scheduled. See this code snippet wh=
ich I tried with MRI 1.8.6 on Windows Vista.

t =3D Thread.new do
  Thread.critical =3D true
  $after_critical =3D true
  Thread.pass
  $after_critical =3D true
  Thread.critical =3D 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 co=
de that happens to do Thread.pass, it will "restart the world" which you wi=
ll 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 sh=
ared data is accessed from two threads, it should be done only if the threa=
ds have set Thread.critical=3Dtrue (ie. use Thread.critical as a mutex with=
out 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 p=
attern 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