> > You already have coroutines, threads, fork/exec, system, and load/
> > require all of which give you different ways to manage multiple
> > threads of control and/or interpret external ruby code.
>
> Right. But this is meaningfully different than all of the above,
> especially within the context of JRuby. JVMs are *expensive* to start,
> but independent Java threads are pretty easy to start. I think that the
> intent is that JRuby is going to introduce Kernel#run_script or
> something similar to it because they want to give JRuby programmers a
> way to start an external script in a lightweight manner. The suggestion
> being made here is to reincorporate it into CRuby, something I support.
>
> In CRuby (without multiple VM instances possible):
>         Kernel#run_script(name, *args)
> would be no different than:
>         Kernel#system("ruby", name, *args)
>
> I'm not fond of the name (maybe Kernel#ruby might be appropriate) but
> the functionality is appropriate, IMO.

I'd only correct this by saying we'd really *like* to add something
like Kernel#run_script/ruby, but unless existing apps were ported to
use it (necessitating its existance in CRuby) it wouldn't accomplish
much for us.

> This would certainly make Rake's default mode of operation for tests
> more portable and reliable.

This is, in fact, the exact use case we're having trouble with. As
JRuby gets closer and closer to full Ruby compatibility, we have been
starting to run more and more test cases against it. Many of these are
most easily run using rake, but two issues with JRuby make that
scenario less than ideal: 1. Launching new JVMs is very expensive, and
2. Java's support for launching and controlling external processes is
far more clunky than it is in POSIX. We have managed to hack around
the launching by intercepting Kernel#system calls, searching for
"ruby" or "jruby" in the beginning of the command, and if found
launching the appropriate script within the same JVM. The two
instances of JRuby are treated independently, as though they were
separate processes. It works, but it makes me itch.

> I think you're trying to overthink this. This is about reducing the
> startup cost for JRuby at a minimum and future Ruby interpreters that
> have multiple VM support. This isn't about pseudo-IPC within those VMs.

I have seen MVM mentioned in at least a couple YARV presentations, and
I think it's a good idea in the long term to be able to launch a new
script in a new Ruby "VM" without launching a whole new process. I
also think the script-launching method would make firing off scripts
easier both now and in the future. Here's hoping it happens!

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