Shri,

Please see my comments below --->


Shri Borde wrote:
> 
> Brent, we are looking for Ruby to officially allow Thread.critical= to be
> implemented as a single non-reentrant mutex. This would help convince
> people writing Ruby libraries in the future to use Thread.critical=
> without assuming that other threads will be descheduled. Otherwise, they
> can push back on JRuby and IronRuby as not being fully-compatible.
> 
> ---> I understand this and agree with your general plan.
> 
> The proposed spec I wrote up would clean things up even more. For example,
> you said "Thread.critical=false exits the critical section, regardless of
> how many times it had been been redundantly set true." However, consider
> the case where thread A sets Thread.critical=true, and then thread B does
> Thread.critical=false. (Note that even MRI will schedule other threads
> under certain circumstances like a newly created thread or if thread A
> does Kernel#sleep). In this case, you cannot force thread A to release the
> mutex. Your wording could possibly still be supported, for example, by
> having thread B create a new mutex and publish that as the single
> non-reentrant mutex to be used henceforth. I think such clean up would be
> good without causing too much incompatilibiles.
> 
> ---> My point was that "clean up" is not an appropriate goal for this very
> old, established interface.
>        Your goal should be to support it, warts and all, as best you can
> with native threading.
> 
>        Your example about Thread A and Thread B needs to support the
> current Thread.critical= behavior.
>        Some apps (that are not open source) will rely on it.  I realize
> this behavior may be harder to
>        implement, but it is required to maintain compatibility.
> 
>        Kernel#sleep does not cause Thread.critical to be set to false. 
> Try running:
>          Thread.critical=true; sleep 1; puts Thread.critical
>        I happen to believe that this should output "false", but it outputs
> "true" on 1.6.8 and 1.8.7
>        I ended up writing a trivial extension called "doze" that sets
> Thread.critical=false before sleeping.
>        I believe Thread.critical should be set to false before every
> blocking operation and the 1.9 patch
>        I sent you to implement Thread.critical does this, but that's not
> how things work now.
> 
> However, we don't have to do all of these changes if compatability is a
> significant concern. As long as descheduling of other threads was not a
> requirement, that would go a long way.
> 
> --->  I believe I do have some code that relies on descheduling.  I
> certainly rely on it when hitting
>         a breakpoint as a means up "stopping the world" while I
> investigate system state.  I also suspect
>         that I rely on it when creating a new thread as way of ensuring
> that no other thread will see
>         its state before it is completely initialized.
>         However, I recognize that descheduling is more or less impossible
> with native threads.
>         So, we have to be pragmatic and move on.
> 
> - brent
> 
> 
> 
> 
> 

-- 
View this message in context: http://www.nabble.com/-ruby-core%3A20999--Supporting-Thread.critical%3Dwith-native-threads-tp21224464p21484624.html
Sent from the ruby-core mailing list archive at Nabble.com.