I'll have a look at your patch. Getting things basically working for now is good, but the eventual plan is to build a new threading subsystem with a scheduler that mimics Ruby's. At that point much of this will go away and we'll have configurable green:native ratios, configurable thread granularity, and improved support for Ruby's own threading semantics (rather than via tricky locks and polls as exists currently).
On 4/18/06, Evan <[EMAIL PROTECTED]> wrote:
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
>
--
Charles Oliver Nutter @ headius.blogspot.com
JRuby Developer @ jruby.sourceforge.net
Application Architect @ www.ventera.com
