Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
64-bit immediate return to prompt on console interrupt before termination #4519
Windows Server 2008 R2 with JRuby 188.8.131.52 and Java8u101 64-bit JVM
When capturing an interrupt, the program will fully terminate before control returns to console prompt. This is the case on 32-bit JVM.
The prompt returns to console prompt immediately, before the JRuby program is terminated.
Test case (foo.rb):
Log contrasting between 32-bit and 64-bit JVM behavior:
I suspect this is due to how the native 'jruby' command fires up the JVM.
The executable we ship is (I believe) compiled for 32-bit to work on both bitwidths. When you are using a 32-bit JVM, it starts up that JVM in the same process via JNI calls. In this case, since there's only a single process, there's no trouble routing interrupts and signals correctly.
However, when you are using our native launcher to start up JRuby on a 64-bit JVM, it can't use the same process space. Instead, it creates a subprocess and pipes IO and events to it. In this case, I suspect that interrupts or signals are not being propagated correctly. What you are seeing is that that 32-bit parent process terminates immediately and leaves the child JVM running; it later terminates on its own but still writes to the same stdio.
Fixing this is going to be a bit tricky, however.
We may be able to ship two executables in our JRuby installer, adding install logic to set up the correct one as the canonical
We could just start saying that JRuby on Windows only supports 64-bit JVMs. This seems a bit like the nuclear option, since Oracle (at least) still provides both 64- and 32-bit downloads of both JDK and JRE.
It may also be possible to fix the launcher's parent/child relationship, but I have not looked into that yet.
FWIW, I have seen this behavior and I don't like it either.
From what I can tell, we're not doing anything wrong per se with our
I'm poking around to see if there's a simple way to tie the console of the parent proess directly to the child, so such events are handled by the child.
I believe we may be able to disable Ctrl+C from being handled by the parent process with a call to
If we call this and specify null for the handler, the parent process will ignore Ctrl+C, and presumably only the child process will handle those events.