Thanks for continuing the thread on ruby-core. Let's see how it goes.
There are couple of minor issues with Thread.stop releasing the lock: * The code will be hard to read as most people probably don't realize that Kernel#stop releases the lock. * Currently, Kernel#sleep does not release the lock. At the least, it should be consistent with Thread.stop. * If the programmer wants to release the lock before stopping the thread, its trivial for the programmer to call Thread.critical=false It's mostly a question of aesthetics and simplicity. The more Thread.critical= can be locked down, the more understandable it will be. But none of these are deal breakers, so I don't feel too strongly. About reentrancy, I am proposing that it *not* be reentrant (unless an implementation choses to support that behavior). So I think we are on the same page. Reentrancy would normally have been a good thing, but since it looks like an assignment, it would read very weirdly in the case below. Thread.critical=true Thread.critical=true # if Thread.critical= was reentrant, this would increment the counter to 2 Thread.critical=false puts Thread.critical # would be weird if this printed true Thread.critical=false Allowing an arbitraty thread to do Thread.critical=false has the same issue as reentrancy. If Thread.critical stayed true after some thread did Thread.critical=false, it would be very misleading. Since the thread cannot actually set Thread.critical to false, it should be an error. About thread terminating while critical is undefined, some implementations may be able to know if the dying thread still holds the lock, but some may not. Especially in the hosted case where some program is using Ruby as a scripting engine, the hosting app may have created the thread and run some Ruby snippet on it which entered the global critical section, but forgot to leave it. In that case, it would be too burdensome to require that the Ruby implementation deal with this case. Hence, the proposal of leaving this undefined. Thanks, Shri -----Original Message----- From: ironruby-core-boun...@rubyforge.org [mailto:ironruby-core-boun...@rubyforge.org] On Behalf Of Charles Oliver Nutter Sent: Monday, January 12, 2009 7:55 AM To: ironruby-core@rubyforge.org Subject: Re: [Ironruby-core] Behavior for Thread.critical= 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. [Shri Borde] There are couple of issues with allowing this: Currently, Kernel#sleep does not release the lock. At the least, it should be consistent with Thread.stop. If the programmer wants to release the lock before * 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 _______________________________________________ Ironruby-core mailing list Ironruby-core@rubyforge.org http://rubyforge.org/mailman/listinfo/ironruby-core
