# Some questions about Ruby 1.9 **URL:** \ **Category:** Ruby\ **Created:** [December 14, 2007, 12:25am UTC](https://www.ruby-forum.com/t/some-questions-about-ruby-1-9/123102 "2007-12-14T00:25:58Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![maz](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/e9c0ed/32.png) [@maz](https://www.ruby-forum.com/u/maz)\ **Post date:** [December 14, 2007, 12:25am UTC](https://www.ruby-forum.com/t/some-questions-about-ruby-1-9/123102/1 "2007-12-14T00:25:58Z")
I fear many of my questions will belong to the “often asked” category but a google search wasn’t too fruitful so here I am… ``` I did find some information on the state of threading but I wanted ``` to clear some things up. If Ruby 1.9 will use system threads, what will happen to the green threads? What will happen to libraries that require green threads, like generator.rb? Will they end up using system threads? If Ruby is using system threads, does that mean Ruby will be thread safe? That is, will we be able to call into an embedded Ruby interpreter from multiple threads? ``` Matz's most "regretting" behaviour of Ruby is that block variables ``` are local to the block. Will this be changed in Ruby 1.9? If so, how will that affect threads, since they’re made from blocks? Will thread variables just leak right out into the defining scope? ``` Finally, if Ruby will now be compiled into bytecode, will we be able ``` to run the bytecode without the Ruby source? Will Ruby be able to do this in an embedded application? ``` These are what are on my mind, at the moment. If I think of any ``` others, I’ll add them to this thread. Thank you… ---
**Author:** ![maz](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/e9c0ed/32.png) [@maz](https://www.ruby-forum.com/u/maz)\ **Post date:** [December 14, 2007, 1:14am UTC](https://www.ruby-forum.com/t/some-questions-about-ruby-1-9/123102/2 "2007-12-14T01:14:02Z")
You can read something here: > **[The Futures of Ruby Threading](https://www.infoq.com/news/2007/05/ruby-threading-futures/)** > > Ruby's thread system is about to undergo big changes in Ruby 1.9, possibly moving from user space threads to kernel threads. Or not. A recent interview with Matz and Sasada Koichi shows some new ideas that are considered. We take a look at the... On Dec 13, 2007 9:25 PM, Just Another Victim of the Ambient M. \< removed\_email\_address@domain.invalid\> wrote: > from multiple threads? > an embedded application? > > These are what are on my mind, at the moment. If I think of any > others, > I’ll add them to this thread. > Thank you… – Regards, Luiz Vitor Martinez C. [Grabber]. (11) 8187-8662 Eletrical Engineer at maua.br ---
**Author:** ![maz](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/e9c0ed/32.png) [@maz](https://www.ruby-forum.com/u/maz)\ **Post date:** [December 14, 2007, 1:31am UTC](https://www.ruby-forum.com/t/some-questions-about-ruby-1-9/123102/3 "2007-12-14T01:31:00Z")
On Fri, 14 Dec 2007 08:25:04 +0900, “Just Another Victim of the Ambient Morality” [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > If Ruby 1.9 will use system threads, what will happen to the green threads? Ruby will no longer have green threads, as such. > What will happen to libraries that require green threads, like generator.rb? > Will they end up using system threads? They’ll be using coroutines (fibers) rather than threads, which are a lighter-weight alternative to green threads. Fibers will also be used to provide external iterators. > If Ruby is using system threads, does that mean Ruby will be thread > safe? That is, will we be able to call into an embedded Ruby interpreter > from multiple threads? Not at this time. The main difficulty is that the Ruby interpreter requires any thread calling into it to have certain special setup done at thread creation time (which Ruby performs when creating its own threads, but won’t have been done for any application-created threads except for the one that initialized the Ruby interpreter). Also, initially, there will be a single large mutex around the Ruby interpreter, preventing any of the Ruby system threads from running concurrently (and also strictly serializing their memory effects). Over time it may be relaxed, however, as synchronization of the interpreter becomes more fine-grained. > Matz’s most “regretting” behaviour of Ruby is that block variables are > local to the block. Will this be changed in Ruby 1.9? I’m a little fuzzy on what happens to variables which are simply implicitly declared. However, block arguments will always be block-local in 1.9, and there is additional syntax for explicitly declaring a variable to be block-local (block-local variable names follow a semicolon in the block argument list). > Finally, if Ruby will now be compiled into bytecode, will we be able > to run the bytecode without the Ruby source? Possibly. JRuby has (experimental) support for YARV-compiled scripts, with -Y compiling a script and -y running a compiled script. I don’t think ruby 1.9 offers a commandline option to do it at this time, but it seems a likely eventual addition. > Will Ruby be able to do this in an embedded application? Assuming support for running bytecode directly in the final 1.9, it would be trivial. -mental