I missed you saying we should nail it first...I already responded on ruby-core.

But I think I agree with everything except for a couple details:

* I think Thread.stop should release the lock as it does now. That's a pretty minor expectation, and since it's already there (and I know at least one library depends on it) it should remain. * I'm dubious about the lock being reentrant. In JRuby I've implemented it using a ReentrantLock, which should count up and count down, but it's not necessarily a requirement. However I think it would be bad if a thread could block by setting critical=true when it's already critical. * I think setting critical=false should only release the lock iff it is held by the current thread, and do nothing otherwise.

I also agree that a thread terminating while critical is undefined behavior. But I think most of these questions could be answered by treating critical= as a globally-shared reentrant mutex.

Thoughts?

Shri Borde wrote:
I asked ruby-core whether descheduling other threads is by spec, but no one 
other than you replied. Any suggestions on how to nudge others to consider it? 
If you want to reply to that thread and provide JRuby's vote of confidence for 
the idea, that might help.

We should nail the complete behavior before taking it to ruby-core. I have 
written up a draft at 
http://blogs.msdn.com/shrib/archive/2009/01/07/proposed-spec-for-ruby-s-thread-critical.aspx.
 Please take a look and comment on whether it works for JRuby. We can move it 
to some wiki if we need to iterate on it...
_______________________________________________
Ironruby-core mailing list
Ironruby-core@rubyforge.org
http://rubyforge.org/mailman/listinfo/ironruby-core

Reply via email to