About a year ago, I rewrote the threading subsystem so that more of the common thread semantics would function correctly. That required a number of tricks and locking mechanisms for stop, wait, critical, etc to actually function as expected. More recently, the exception-handling subsystem has also been rewritten, and it's likely that it is not correctly handling ensured blocks.
I'll look into the issue at my earliest convenience. Is it true that ensure blocks should fire when killing a thread? This seems sorta right, but sorta wrong.
On 4/11/06,
Evan <[EMAIL PROTECTED]> wrote:
OK, so here's my thoughts so far:
EvaluationState.begin handles rescue and ensure blocks, by catching
JumpExceptions. It is trivial to add something here that catches the
ThreadKill exception, or possibly it should be changed to itself be a
JumpException (probably the latter).
The problem is, that even when we catch and handle this exception and
start running ensured blocks, every executeNext() again throws a
ThreadKill exception without executing, which really doesn't help here.
The fix is probably to modify RubyThread to throw the exception only once,
and set some flag accordingly. One issue here is what should happen to a
Thread which is in an ensure block because it is killed and then someone
comes along and runs Thread.kill again -- do we break out of the block? I
don't think so, and this simplifies it: no matter what, we throw the
ThreadKill *only* once.
ensure blocks should then be able to be handled correctly on Thread#kill.
Of course, it looks like there is a separate issue with Thread#kill
sometimes being very, very mean which might not give the thread a chance
to handle anything at all, but I haven't looked into this and its a
seperate issue.
I'll be gone for a week so I won't be getting a chance to try this out for
awhile. If anyone else takes it on, great, otherwise this is my top
priority come Monday.
Evan
Evan wrote:
> Am I crazy, or does JRuby's implementation kill a thread w/o running any
> ensure blocks in that thread?
>
> This seems like it's a blocker for any thread programming that needs any
> level of robustness (does Thread.critical even get reset?). Before I go
> diving in here, though, has anyone already had thoughts about how this
> *should* happen?
>
> Evan
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting
> language
> that extends applications into web and mobile media. Attend the live
> webcast
> and join the prime developer group breaking into this new coding
> territory!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642
> _______________________________________________
> Jruby-devel mailing list
> Jruby-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jruby-devel
>
--
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmdlnk&kid0944&bid$1720&dat1642
_______________________________________________
Jruby-devel mailing list
Jruby-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jruby-devel
--
Charles Oliver Nutter @ headius.blogspot.com
JRuby Developer @ jruby.sourceforge.net
Application Architect @ www.ventera.com
