Thanks Charles!
> You should file this as a bug.
Done: http://jira.codehaus.org/browse/JRUBY-4610
> 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.
This makes sense, though it appears that JRuby does have signal
handlers for SIGHUP & SIGINT.
I can get get to the Procs like so: old_handler = trap('HUP') {};
old_handler.class #=> Proc
I'd expect the fix would be a change to these existing JRuby signal handlers.
For some additional context, our JRuby application is consuming JMS
messages from a Websphere MQ instance. The 'ensure' blocks that we'd
like to run close connections to this queue gracefully. Not doing this
upsets the folks who manage these queues :)
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
