On Fri, Feb 26, 2010 at 6:37 PM, Abhijit Hiremagalur
<a...@pivotallabs.com> wrote:
> We think we've found an inconsistency between how JRuby and MRI handle
> SIGHUP signals (and others like SIGINT). In MRI any ensure blocks in
> the method being executed get run but under JRuby this doesn't appear
> to be the case.
>
> We've attached a test that we think exposes the issue, i.e. the JRuby
> test fails and the MRI test passes. It works if you have MRI on your
> PATH as 'ruby' and JRuby on your PATH as 'jruby'.
You should file this as a bug.
Note also that we don't register signal handlers for all the same
signals that MRI does, largely because the JVM uses many of them for
its own purposes under normal circumstances (and we felt it would be
downright rude to hijack those signals without good reason).
SIGQUIT is another example of a signal we don't process the same way
as MRI; we don't trap it and don't raise Interrupt, since default JVM
behavior for SIGQUIT is to do a hard exit of all threads. Who should
we break? JVM users that expect C-c to terminate the JVM or Ruby users
that expect C-c to raise Interrupt? SIGHUP is likely a similar case.
> We've also tried this with the latest version of JRuby from github.
>
> At first we thought this might be because the JVM wasn't passing the
> signal, but if we trap the signal and process it manually it works the
> same way in MRI and JRuby.
Yes, that's what we recommended to someone who needed the SIGQUIT
Interrupt behavior for their application. Manually trapping the
signals appears to work fine...but we're not (currently) comfortable
doing it by default because of how it breaks JVM users expectations.
- Charlie
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
