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 jruby.exe. However, if it picks the 64-bit version and a user tries to run a 32-bit JVM, it will either behave like the mismatched case above or not be able to launch JRuby at all.
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.
Windows Server 2008 R2 with JRuby 220.127.116.11 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:
The text was updated successfully, but these errors were encountered: