This seems to fix it. Patch is against latest *anonymous* cvs, which I understand is out of date.
The changes are: 1) make ThreadKill a derived class of JumpException 2) make a handler for ThreadKill similar to that for RaiseException, except without any rescuing code. 3) add a flag to RubyThread to ensure that ThreadKill is thrown only once. I think there may be a race condition between Thread.exit and Thread#kill where ThreadKill could be thrown twice, but I think the effect of this race condition ends up being correct -- in other words, we don't *really* need ThreadKill to be thrown only once, we just need it not to be thrown at every instruction. I think... Evan P.S. I noticed pollThreadEvents happens *both* at every execute *and* at every newline. Shouldn't it be at one or the other? (My votes go to every execute). Charles O Nutter wrote: > Perhaps it's similar to Thread.raise, but without raising anything. Should > be an easy fix. > > On 4/12/06, Nawrocke Kelly <[EMAIL PROTECTED]> wrote: >> >> I ran some test cases in C Ruby and yes they are executed. so kill >> doesn't mean kill, its more of a polite "please stop at your earliest >> convenience and don't do anything silly in your ensure blocks". >> >> kelly >> >> On Apr 12, 2006, at 7:36 PM, Charles O Nutter wrote: >> >> > My friend, you have stumbled onto the dark underbelly of Ruby and >> > JRuby: Threads. >> > >> > 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 >> >> >> >> ------------------------------------------------------- >> 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 >
ensure.patch
Description: Binary data
