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
