Some questions about Ruby 1.9

Ruby
1

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…

2

You can read something here:

On Dec 13, 2007 9:25 PM, Just Another Victim of the Ambient M. <
[email protected]> 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

3

On Fri, 14 Dec 2007 08:25:04 +0900, “Just Another Victim of the Ambient
Morality” [email protected] 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