JRuby (please use github issues at http://bugs.jruby.org)
  1. JRuby (please use github issues at http://bugs.jruby.org)
  2. JRUBY-5681

jruby doesn't fork the backtick command when the command is jruby

    Details

    • Type: Bug Bug
    • Status: Resolved Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: JRuby 1.6
    • Fix Version/s: JRuby 1.7.0.pre1
    • Component/s: None
    • Labels:
      None
    • Environment:
      JRuby 1.6 on Windows
    • Number of attachments :
      2

      Description

      Attached are two files, foo.rb and bar.rb. Copy these files to the jruby bin directory and type:

      jruby.exe foo.rb

      or (if not on Windows):

      jruby foo.rb

      Then bring up procexp (or top) and watch to see if any subprocess jruby is created.

      I see that no additional jruby process is created. MRI c ruby does not have this behavior. It will create two ruby processes.

      I assume this is an optimization but it's a bad one. If I wanted to simply run another ruby script from my current ruby process, I would load or require it and then call it. However, this optimization is playing havoc with jruby's idea of what modules it has loaded. Our jruby scripts load jar which themselves call System.loadLibrary() to load DLLs. When the jar is loaded the loadLibrary call should happen once and life is good. However, this "optimization" in the backtick logic is causing that java code to execute twice and make our original jruby script very unstable.

      We can work around this by using IO.popen and we'll do that, however, I really think it breaks expectation to have backtick NOT create another process is every situation, including when the backtick command is another instance of jruby itself.

      1. child.rb
        0.0 kB
        Jeff Solomon
      2. parent.rb
        0.0 kB
        Jeff Solomon

        Activity

        Hide
        Jeff Solomon added a comment -

        OK, a much simpler way of demonstrating this bug: See attached parent.rb and child.rb file. Copy those files to the jruby/bin directory and type 'jruby.exe parent.rb'. The output for me is:

        % jruby.exe parent.rb
        parent pid: 6804
        child pid 6804

        which shows that they are running in the same process. Grab MRI C ruby and do the same thing. I get this:

        % ruby.exe parent.rb
        parent pid: 5528
        child pid 1512

        Different processes

        Show
        Jeff Solomon added a comment - OK, a much simpler way of demonstrating this bug: See attached parent.rb and child.rb file. Copy those files to the jruby/bin directory and type 'jruby.exe parent.rb'. The output for me is: % jruby.exe parent.rb parent pid: 6804 child pid 6804 which shows that they are running in the same process. Grab MRI C ruby and do the same thing. I get this: % ruby.exe parent.rb parent pid: 5528 child pid 1512 Different processes
        Hide
        Charles Oliver Nutter added a comment -

        Until JRuby 1.7, we always attempted to keep 'jruby' subprocesses in the same JVM by launching a new instance of JRuby. As of JRuby 1.7, however, we default to always launching an external process.

        Show
        Charles Oliver Nutter added a comment - Until JRuby 1.7, we always attempted to keep 'jruby' subprocesses in the same JVM by launching a new instance of JRuby. As of JRuby 1.7, however, we default to always launching an external process.

          People

          • Assignee:
            Charles Oliver Nutter
            Reporter:
            Jeff Solomon
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: