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 ,, , 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:

Reply via email to