------art_125562_3176139.1153510125741
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On 7/21/06, why the lucky stiff <ruby-core / whytheluckystiff.net> wrote:
>
> On Sat, Jul 22, 2006 at 02:50:24AM +0900, Charles O Nutter wrote:
> > Second, RCR328 details a potential mechanism for launching a Ruby script
> > either out-of-process (spawned) or as an in-process MVM.
>
> Oh, thanks for pointing this out.  I'm working on a Sandbox.run(path)
> which will
> run the script and set $0, ARGV, etc appropriately.  Ruby could just alias
> run_script to that.  I've already got Script.load working and globals are
> sandboxed, so I'm very close to getting this done.


Feel free to throw in your vote, if you haven't already. If we could get
things like Rake switched over to Kernel#run_script or #ruby or whatever in
the near term, we JRubyists could remove our ugly hack to force .rb
Kernel#system calls to run in process. On top of all that it would be a
trivial addition to C Ruby 1.8.x since it would just spawn a new process.
Requiring your sandbox extension could point Kernel#ruby at the Sandbox
instead, and on JRuby Kernel#ruby would simply start up another JRuby
runtime. It seems like a logical thing to add.

> With _why's sandboxing extension, JRuby's existing MVM support, and YARV's
> > future MVM support, it would seem we're all working toward similar
> goals.
>
> Yeah, once things start to stabilize, we should definitely craft some kind
> of an
> overarching API for managing multiple interpreters.  I've started to carve
> out
> the stuff I'd like to expose in sand_table.h.  Stuff like defining classes
> in a
> specific interpreter, copying methods from one interpreter to another,
> copying
> interpreter insides, etc.


I'll try to take a look at that when I have a moment. The MVM stuff is
mostly working, so it hasn't been a big focus of late, but your sandbox work
brought it to mind again. We had not yet begun to consider management of
multiple interpreters in the same process; maybe your work will give us some
ideas. There's also a world of management libraries and extensions for
exactly this sort of purpose in Java (e.g. JMX, Java Management Extensions)
so we've got some room to work.

One of the things I keep wondring: a way to serialize the interpreter and
> pass
> it between YARV, JRuby, and Ruby 1.8.5+.  We wouldn't be able to serialize
> some
> things, but what's left could be useful.


Making that interpreter-independent would be tricky, but it may be possible.
Other than things like threads, IO channels, and so on, JRuby could probably
serialize out right now using basic Java serialization. That doesn't,
however, provide a path for other Ruby implementations to interoperate. At a
minimum I'd think you'd need to specify:

- standard format for serializing all in-memory objects and rehydrating them
on the other side (everything in ObjectSpace, or more?)
- standard semantics for handling/rehydrating running threads, io channels,
etc that would not be serializable (or not easily...C Ruby 1.8's green
threads might serialize, but JRuby and YARV's native threads never will)
- lastly, I would *really really* like a solid binary marshalling spec for
Ruby. We have had to implement JRuby's marshalling a piece at a time by
reading Ruby's C code, and we've no guarantees it won't change. There's no
promise of interoperability without some kind of spec.

I think you'll need to do some of the first two to handle switching context
between interpreters...since the C impl will necessarily only be able to run
one of the interpreters at a time, you'll need to figure out the minimum set
of state to memoize when switching contexts, and probably have your
management service above all the interpreters. If you want to get really
complicated, you would tie it into the green thread timeslicing, so that
interpreters could "virtually" run in parallel...although switching
interpreter contexts every 10ms might be a bit heavy.

There's a lot of potential here.

-- 
Charles Oliver Nutter @ headius.blogspot.com
JRuby Developer @ www.jruby.org
Application Architect @ www.ventera.com

------art_125562_3176139.1153510125741--