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

Reply via email to