On Tue, Mar 2, 2010 at 1:22 PM, Abhijit Hiremagalur
<a...@pivotallabs.com> wrote:
>> 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.
I believe these are faked; we do not hook either HUP or INT by default
(and thanks, I got QUIT and INT mixed up).
> 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 :)
There's another option: don't rely on SIGHUP :) No other JVM-based
program would.
- Charlie
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
