Accessing ruby 1.9 interpreter from other threads

Ruby
1

Hi,

I seem to recall hearing 1.9 is using native threads now.

If so, does that mean it’s now safe for multiple OS threads
to call into the 1.9 ruby interpreter, and eval or execute
ruby code? (I’m assuming some sort of interpreter lock would
need to be grabbed.)

Thanks,

Bill

2

Hi,

At Tue, 28 Aug 2007 19:33:02 +0900,
Bill K. wrote in [ruby-talk:266532]:

I seem to recall hearing 1.9 is using native threads now.

If so, does that mean it’s now safe for multiple OS threads
to call into the 1.9 ruby interpreter, and eval or execute
ruby code? (I’m assuming some sort of interpreter lock would
need to be grabbed.)

And to bind calling native thread a ruby thread. But still not
provided now.

3

Nobuyoshi N. wrote:

And to bind calling native thread a ruby thread. But still not
provided now.

A similar mechanism is used in JRuby to “adopt” incoming Java threads as
Ruby threads, allowing them to participate in thread events like kill
and raise. But there’s nothing explicit about it; threads that haven’t
been adopted are adopted automatically. Can’t this be done
automatically?

  • Charlie
4

Hi,

At Wed, 29 Aug 2007 19:16:00 +0900,
Charles Oliver N. wrote in [ruby-talk:266657]:

A similar mechanism is used in JRuby to “adopt” incoming Java threads as
Ruby threads, allowing them to participate in thread events like kill
and raise. But there’s nothing explicit about it; threads that haven’t
been adopted are adopted automatically. Can’t this be done automatically?

Does that “adopt” occur in any call to ruby? Isn’t it
performance overhead?

5

Nobuyoshi N. wrote:

performance overhead?
Not really, if the thread hasn’t been adopted it just constructs a new
Ruby thread to wrap it and a “thread context” to govern frames, scopes,
etc for Ruby execution. That’s a one-time hit that only happens the
first time a normal Java thread enters Ruby code. From then on it
largely just looks like any other Ruby thread.

  • Charlie