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

I disagree on most points, since 1.8 is going to remain the most  
commonly used "spec" for quite a while, and the global mutex is a  
reasonable compromise that meets most use cases. Unless there are a  
large number of libraries depending on running on non-MRI impls and  
using critical= and relying on it's thread descheduling  
characteristics, we are penalizing the vast majority of JRuby or  
IronRuby users that don't for an extremely rare edge case. That's not  
very pragmatic. And if nothing else, we alternative implementers have  
learned to be very pragmatic.

Pragmatism would be doing exactly what Shri has done: propose a  
solution that appears to meet the 90+% case, actively search for  
libraries that solution would break, and evaluate the results. If  
there are such breaking cases, see if they can be fixed or weigh their  
relevance. If there are no such cases, proceed with said solution and  
be prepared to address undiscovered failures if any are reported. With  
JRuby spinning a new release every other month, the impact is minimal.

I suppose we can volunteer JRuby as a guinea pig for this new  
definition of critical=, and see how it goes. JRuby 1.1.7 will  
implement critical= as a global mutex. We shall see how it goes :)

- Charlie (mobile)

On Jan 19, 2009, at 2:28, Brent Roman <[e-mail]> wrote:

>
> Charlie & Shri,
>
> Ruby 1.9 doesn't support Thread.critical=  However, when I last looked
> (about a year ago) it still had a "Giant VM Lock"  to prevent  
> multiple Ruby
> threads from running in parallel.  MRI struck this compromise  
> because it
> must to be able to run existing 'C' extensions unmodified.   In this
> threading environment it is quite easy to add this support for
> Thread.critical=.  I'm guessing the decision to delete  
> Thread.critical= was
> to open the door for parallel threading in Ruby 2.x sometime in the  
> future.
>
> Ruby 1.9 *does* support Thread.exclusive {} by mapping this onto a  
> global
> Mutex.  If you don't care about backward compatibility, then why do  
> you need
> to blaze your own trail here?
> Why not do exactly as v1.9 has already done?
>
> The "cross-impl critical= spec" is not supported by any existing
> implementation.
>
> Thread.critical is a flag that affects thread scheduling.  It is not a
> Mutex.
> It commonly gets set when it is already true and cleared when it is  
> already
> false.
> Both these operations are NOPs in the current implementation!
> One doesn't have to get deep into Threading Zen to see that the spec  
> you
> have posted will cause most existing code that uses Thread.critical=  
> in any
> way
> other than as a means of implementing a simple Mutex to fail.
>
> The only way to support the existing Thread.critical= behavior in a
> meaningful way is in the context of a reduced performance threading  
> model
> where only one Ruby thread runs at a time.  If there were another  
> way, I
> think v1.9 would have retained it.
>
> You've got two choices, as I see it.  Remove Thread.critical , or  
> maintain
> an optional thread scheduling mode with a Giant VM Lock to ensure  
> that only
> one thread runs at a time for backward compatibility with v1.8 and  
> before.
>
> Everything you've posted about the "vigorous checkpointing" JRuby  
> does to
> support Thread.critical= indicates to me that even this valiant  
> effort fails
> to implement Thread.critical in a parallel threading VM.  So, yes,  
> in a
> nutshell, "It is better to make a hard break".  Drop support for
> Thread.critical= unless you intend to support the threading  
> environment on
> which it depends.
>
> - brent
>
> -- 
> View this message in context: http://www.nabble.com/-ruby-core%3A20999--Supporting-Thread.critical%3Dwith-native-threads-tp21224464p21539447.html
> Sent from the ruby-core mailing list archive at Nabble.com.
>
>