JRuby compatability issue #330

Closed
sharkos opened this Issue Mar 13, 2013 · 7 comments

Comments

Projects
None yet
6 participants
@sharkos

sharkos commented Mar 13, 2013

When using 'rhc' to clone the repo using the JRuby VM, calling 'git' using fork fails.

ose]$ rhc git-clone firstphp
Password: ****
NotImplementedError: fork is not available on this platform
fork at org/jruby/RubyKernel.java:1766
do_popen at /home/ctusa/dev/jruby-1.7.3/lib/ruby/gems/shared/gems/open4-1.3.0/lib/open4.rb:58
popen4 at /home/ctusa/dev/jruby-1.7.3/lib/ruby/gems/shared/gems/open4-1.3.0/lib/open4.rb:30
spawn at /home/ctusa/dev/jruby-1.7.3/lib/ruby/gems/shared/gems/open4-1.3.0/lib/open4.rb:331
timeout at org/jruby/ext/timeout/Timeout.java:105
spawn at /home/ctusa/dev/jruby-1.7.3/lib/ruby/gems/shared/gems/open4-1.3.0/lib/open4.rb:330
call at org/jruby/RubyProc.java:249
chdir at /home/ctusa/dev/jruby-1.7.3/lib/ruby/gems/shared/gems/open4-1.3.0/lib/open4.rb:369
spawn at /home/ctusa/dev/jruby-1.7.3/lib/ruby/gems/shared/gems/open4-1.3.0/lib/open4.rb:329
run_with_tee at /home/ctusa/dev/jruby-1.7.3/lib/ruby/gems/shared/gems/rhc-1.4.8/lib/rhc/helpers.rb:493
git_clone_repo at /home/ctusa/dev/jruby-1.7.3/lib/ruby/gems/shared/gems/rhc-1.4.8/lib/rhc/git_helpers.rb:65
git_clone_application at /home/ctusa/dev/jruby-1.7.3/lib/ruby/gems/shared/gems/rhc-1.4.8/lib/rhc/git_helpers.rb:23
run at /home/ctusa/dev/jruby-1.7.3/lib/ruby/gems/shared/gems/rhc-1.4.8/lib/rhc/commands/git_clone.rb:22
send at org/jruby/RubyBasicObject.java:1683
send at org/jruby/RubyKernel.java:2107
execute at /home/ctusa/dev/jruby-1.7.3/lib/ruby/gems/shared/gems/rhc-1.4.8/lib/rhc/commands.rb:201
to_commander at /home/ctusa/dev/jruby-1.7.3/lib/ruby/gems/shared/gems/rhc-1.4.8/lib/rhc/commands.rb:192
call at org/jruby/RubyProc.java:249
call at /home/ctusa/dev/jruby-1.7.3/lib/ruby/gems/shared/gems/commander-4.1.3/lib/commander/command.rb:180
run at /home/ctusa/dev/jruby-1.7.3/lib/ruby/gems/shared/gems/commander-4.1.3/lib/commander/command.rb:155
run_active_command at /home/ctusa/dev/jruby-1.7.3/lib/ruby/gems/shared/gems/commander-4.1.3/lib/commander/runner.rb:402
run! at /home/ctusa/dev/jruby-1.7.3/lib/ruby/gems/shared/gems/rhc-1.4.8/lib/rhc/command_runner.rb:61
run! at /home/ctusa/dev/jruby-1.7.3/lib/ruby/gems/shared/gems/commander-4.1.3/lib/commander/delegates.rb:11
start at /home/ctusa/dev/jruby-1.7.3/lib/ruby/gems/shared/gems/rhc-1.4.8/lib/rhc/cli.rb:42
(root) at /home/ctusa/dev/jruby-1.7.3/lib/ruby/gems/shared/gems/rhc-1.4.8/bin/rhc:18
load at org/jruby/RubyKernel.java:1046
(root) at /home/ctusa/dev/jruby-1.7.3/bin/rhc:23

@BanzaiMan

This comment has been minimized.

Show comment Hide comment
@BanzaiMan

BanzaiMan Mar 27, 2013

Contributor

For the time being, please use MRI. For short-lived scripts like rhc, JRuby's startup time might be too high a price to pay.

Contributor

BanzaiMan commented Mar 27, 2013

For the time being, please use MRI. For short-lived scripts like rhc, JRuby's startup time might be too high a price to pay.

@mrbrdo

This comment has been minimized.

Show comment Hide comment
@mrbrdo

mrbrdo Oct 27, 2013

I think this needs to be addressed. This should be pretty easy to address, I don't see why you would absolutely need to use fork for such a simple utility.

mrbrdo commented Oct 27, 2013

I think this needs to be addressed. This should be pretty easy to address, I don't see why you would absolutely need to use fork for such a simple utility.

@BanzaiMan

This comment has been minimized.

Show comment Hide comment
@BanzaiMan

BanzaiMan Oct 28, 2013

Contributor

Replacing the git functionalities we need with those that do not require forking is not a simple task. Our resources are limited, and this is not a high priority at this time.

I encourage you to drum up other users' support for this issue at https://www.openshift.com/ideas. This will help us truly evaluate what is really important to our users.

Thank you.

Contributor

BanzaiMan commented Oct 28, 2013

Replacing the git functionalities we need with those that do not require forking is not a simple task. Our resources are limited, and this is not a high priority at this time.

I encourage you to drum up other users' support for this issue at https://www.openshift.com/ideas. This will help us truly evaluate what is really important to our users.

Thank you.

@sharkos

This comment has been minimized.

Show comment Hide comment
@sharkos

sharkos Oct 28, 2013

This can be accomplished quite easily by using a C call via FFI to call an external command. Here is a code snippet from a program I wrote to load 'NANO' using C. Java.exe does not properly handle the full screen capability of NCurses, so it had to be executed using a C fork instead. Something similar to this should work :

 # Load FFI Support
 require 'ffi'

 # LIBC exec call.
 module JExec
    extend FFI::Library
    ffi_lib("c")
    attach_function :execvp, [:string, :pointer], :int
    attach_function :fork, [], :int
  end

  # Load filename using rnano
  def exec_editor
     strptrs = []
     strptrs << FFI::MemoryPointer.from_string("/bin/rnano")   # Restricted Nano
     strptrs << FFI::MemoryPointer.from_string("-t")           # -t for use tmpfile (no save prompt)
     strptrs << FFI::MemoryPointer.from_string("#{@filename}") # generated tmp filename 
     strptrs << nil

     # Now load all the pointers into a native memory block
     argv = FFI::MemoryPointer.new(:pointer, strptrs.length)
     strptrs.each_with_index do |p, i|
      argv[i].put_pointer(0,  p)
     end
     if JExec.fork == 0
      JExec.execvp("/bin/rnano", argv)
     end
     Process.waitall
  end

sharkos commented Oct 28, 2013

This can be accomplished quite easily by using a C call via FFI to call an external command. Here is a code snippet from a program I wrote to load 'NANO' using C. Java.exe does not properly handle the full screen capability of NCurses, so it had to be executed using a C fork instead. Something similar to this should work :

 # Load FFI Support
 require 'ffi'

 # LIBC exec call.
 module JExec
    extend FFI::Library
    ffi_lib("c")
    attach_function :execvp, [:string, :pointer], :int
    attach_function :fork, [], :int
  end

  # Load filename using rnano
  def exec_editor
     strptrs = []
     strptrs << FFI::MemoryPointer.from_string("/bin/rnano")   # Restricted Nano
     strptrs << FFI::MemoryPointer.from_string("-t")           # -t for use tmpfile (no save prompt)
     strptrs << FFI::MemoryPointer.from_string("#{@filename}") # generated tmp filename 
     strptrs << nil

     # Now load all the pointers into a native memory block
     argv = FFI::MemoryPointer.new(:pointer, strptrs.length)
     strptrs.each_with_index do |p, i|
      argv[i].put_pointer(0,  p)
     end
     if JExec.fork == 0
      JExec.execvp("/bin/rnano", argv)
     end
     Process.waitall
  end
@mrbrdo

This comment has been minimized.

Show comment Hide comment
@mrbrdo

mrbrdo Oct 28, 2013

All this is unnecessary.

I can see very clearly that whenever you try to use fork, you check for Windows, and if it's Windows you use an alternative solution, which will also work fine on JRuby. What you said ("Replacing the git functionalities we need with those that do not require forking is not a simple task.") is definitely untrue.

Additionally, you can use IO.popen4 on JRuby (it's in the standard library), instead of using the open4 gem which does not work on JRuby. The only other place where you use fork (and the only place where you use it directly) is in highline_extensions for paging, but again, you disable this on Windows (and it can be disabled on *nix as well using env vars, iirc), so you can probably do the same on JRuby.

I hope you aren't under the impression that JRuby not supporting fork means it doesn't support system/`/spawn/exec etc. - that would be very very far from the truth.

PS: To check for JRuby you can use RUBY_PLATFORM == 'java'

Like I said it's a really easy fix, depending on how properly you want to fix it, it will be 2-8 lines of changes.

mrbrdo commented Oct 28, 2013

All this is unnecessary.

I can see very clearly that whenever you try to use fork, you check for Windows, and if it's Windows you use an alternative solution, which will also work fine on JRuby. What you said ("Replacing the git functionalities we need with those that do not require forking is not a simple task.") is definitely untrue.

Additionally, you can use IO.popen4 on JRuby (it's in the standard library), instead of using the open4 gem which does not work on JRuby. The only other place where you use fork (and the only place where you use it directly) is in highline_extensions for paging, but again, you disable this on Windows (and it can be disabled on *nix as well using env vars, iirc), so you can probably do the same on JRuby.

I hope you aren't under the impression that JRuby not supporting fork means it doesn't support system/`/spawn/exec etc. - that would be very very far from the truth.

PS: To check for JRuby you can use RUBY_PLATFORM == 'java'

Like I said it's a really easy fix, depending on how properly you want to fix it, it will be 2-8 lines of changes.

@vbalazs

This comment has been minimized.

Show comment Hide comment
@vbalazs

vbalazs Apr 19, 2014

related: Bug 1088960: Skip forking for jruby #580

vbalazs commented Apr 19, 2014

related: Bug 1088960: Skip forking for jruby #580

@tiwillia

This comment has been minimized.

Show comment Hide comment
@tiwillia

tiwillia Jul 9, 2015

Member

This was fixed with #580 in BZ #1088960 as mentioned above.

@danmcp this can be closed

Member

tiwillia commented Jul 9, 2015

This was fixed with #580 in BZ #1088960 as mentioned above.

@danmcp this can be closed

@danmcp danmcp closed this Jul 9, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment