Since YARV (and therefore Ruby 2.0) seems to be planning switching from Green Threads to Native Threads (or at least that's what I get from looking through the cryptic notes at http://glu.ttono.us/articles/2005/10/14/yarv-progress-report) do we even *want* to implement green threads? If we are compiling to Java and wanting full Java->Ruby instead of just Ruby->Java, we probably *want* Ruby threads to be native threads, no? Unless of course its simply not possible to get the same behaviour.
If we made a thread manager / scheduler as a seperate thread, but left all Ruby threads as native java threads -- making the manager / scheduler run only one at a time -- couldn't we get the same effect as having green threads w/ a minimum of reprogramming and also give the Java->Ruby side of this a better view / handle on threads created in Ruby? Also, if we could find a way to keep the semantics of Ruby threads while going totally native, this seems like it would provide a better upgrade path. ///End random brain dump Any update on getting my patch included? Evan Charles O Nutter wrote: > The granularity of thread events is still up for debate. Every newline makes > some sense, but it may not be granular enough. I'm not sure what Ruby does, > but I did not make any major modification to the threading granularity when > I rewired it. > > 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 > ------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid0709&bid&3057&dat1642 _______________________________________________ Jruby-devel mailing list Jruby-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jruby-devel
