[ruby-core:21410] Re: Supporting Thread.critical=with native threads

Brent Roman wrote:
> There should be no wriggle room in the spec about this.  The existing
> behavior may not be optimal, but it is simple and well established.  Old
> code depends on it, warts and all.  New code should avoid the use the
> Thread.critical entirely.

Given that 1.9 doesn't even have critical=, I'm not sure how backward 
compatibility is part of this discussion. We're talking about specifying 
critical= in such a way that the only *guaranteed* behaviors are 
supportable by a single global mutex. These behaviors should be a subset 
of behaviors promised by the current green-threaded critical= in MRI. So 
on any parallel-threading implementation, with this "cross-impl 
critical= spec" we will have an official set of behaviors users can 
expect to work. I don't think anyone suggested changing 1.8.6; we just 
want to specify critical= in a cross-impl way. 1.8.6's current superset 
behavior would remain intact.

> For native threaded implementations, all of this can, and probably should,
> be implemented with a single, non-reentrant mutex.  Thread.critical=true
> when it was false would lock the global mutex and may block waiting for it. 
> Thread.critical=false when it was true would unlock it.
> 
> I think this approach is straightforward, allows native threaded
> interpreters to avoid expensive checkpointing and maintains very good
> compatibility with existing Ruby scripts.  I would suggest that JRuby keep
> its existing checkpointing available as a run-time option for maximum
> compatibility, analogous to its support of ObjectSpace.  Thus, JRuby could
> continue to support those few scripts that do depend on the fact that, in
> MRI and other green threaded implementations, Thread.critical=true can be
> used to keep all other threads from running.

Unfortunately the problem with the 1.8.6 behavior is that it's 
impossible to guarantee even with vigorous checkpointing unless you 
don't execute anything in parallel. Is it better to make a hard break 
and support the mutex version only or pretend to support the 1.8.6 
behavior but do it unreliably?

- Charlie