This is an opinion piece; it is meant to convince you that the
jruby.launch.inproc property should default to false.
Summary: Trying to run new jruby or ruby instances in the same process
is dangerous; the jruby.launch.inproc property controls this behavior
and should prefer safety and accuracy (a value of false) over
performance (a value of true).
Longer version: When you use the system or ` methods to run a command,
JRuby will decide whether it should run the command in a new process
or if it should run the command as a new Ruby instance inside of the
current process. A number of things affect JRuby's decision:
1. The jruby.launch.inproc property.
2. Whether the command appears to be launching another Ruby program;
specifically, whether the command contains 'jruby,' 'ruby,' 'irb,' or
'.rb.' In these cases, the command is run inside of the current process.
3. Whether the command contains directives to the shell, like '<,'
'>,' and '|.' In these cases, the command is run through a subshell.
Number 1 overrides the other two: if jruby.launch.inproc is false,
then none of the other factors matter. Right now the property's value
defaults to true. This is dangerous for several reasons.
1. There is a lot of complexity in deciding whether the command should
execute in a new process or the existing process. JIRA issues http://jira.codehaus.org/browse/JRUBY-1544
, http://jira.codehaus.org/browse/JRUBY-1557, http://jira.codehaus.org/browse/JRUBY-1579
, http://jira.codehaus.org/browse/JRUBY-2244 have, to my knowledge,
all stemmed from incorrectly identifying and executing the given
command. (There is also some complexity in deciding whether to execute
commands using Java's exec or a subshell; this is a slightly
different, but related issue). The example given in JRUBY-1557 is
clearly contrived, but I ran into the same problem this morning when I
was making a test for jruby and jrubyc. That test was invoking new
jruby processes with different CLASSPATHs. I had to set the inproc
property to false in order to get the tests working.
2. Different Ruby instances running in the same process need to be
careful not to corrupt each other. I have not run into any concrete
examples for this. But I can imagine a situation where one Ruby
instance uses native libraries via JNA, causes a memory fault, and
takes down the entire VM. Please correct me if I am wrong about this.
Either way, we need to be damn sure that the code responsible for
running multiple instances can keep those instances from corrupting
each other.
3. MRI gives you a subshell and people expect a subshell. The errors I
have run into were completely non-obvious. The problem with passing
environment variables, in particular, took me a long time to track
down. There is no good feedback from JRuby when running a command went
wrong. It is frustrating when the most obvious of things doesn't
appear to be working.
Because of the complexity and inaccuracy in launching new Ruby
instances vs. new subshells, I suggest that jruby.launch.inproc
default to false. Those who identify a need for increased ruby launch
performance may turn it on.
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
