Trapping SIGNINT

Ruby JRuby
1

Hello,
I’ve found various other posts suggesting that CTRL-C is handled by the
JVM
… I’m trying to figure out what the current status is.
In a trivial script (trap + while true) it appears to be handled fine,
but
when using java objects my script is aborted halfway through the trap
block
(perhaps when it calls back into java land?):

Whatever the intended behaviour, I would expect it to be “nicer” than
this
experience - either raising when I attempt to trap the signal, or
running
the entire block, not just half of it.

Xavier

2

Hmm, that should work ok. Can you come up with an example that doesn’t
use Neo4j and shows the same problem? I’d like to try to reproduce.

FWIW, IRB, RSpec, and others hook SIGINT in JRuby and work fine (as
far as I know).

  • Charlie
3

On Tue, Sep 6, 2011 at 11:23 AM, Charles Oliver N.
[email protected]wrote:

Hmm, that should work ok. Can you come up with an example that doesn’t
use Neo4j and shows the same problem? I’d like to try to reproduce.

I have just tried and was unable. My script should work with only a gem install neo4j, it’s all in-process and doesn’t require an external
install
of neo4j (I don’t think).

FWIW, IRB, RSpec, and others hook SIGINT in JRuby and work fine (as
far as I know).

The only difference I can see is that these don’t call back into java
objects in the trap, but then just using simple java apis
(System.currentTimeInMillis, for instance) I couldn’t reproduce.

Xavier

4

On Tue, Sep 6, 2011 at 1:15 PM, Xavier S. [email protected] wrote:

Xavier

FWIW, on Windows 7 32bit using not-quite-your-snippet
$stopping = falsetrap("SIGINT") { $stopping = true puts "1" # The cal - Pastebin.com I get the following.

Seems the sleep 1 call in the SIGINT handler is confounding
JRuby…removing it works as expected. Not apples-to-apples, but I
don’t understand why the presence of the SIGINT handler sleep seems to
impact JRuby.

C:\Users\Jon\Documents\RubyDev\sandbox>jruby -v trap_sigint.rb
jruby 1.6.4 (ruby-1.8.7-p330) (2011-08-23 17ea768) (Java HotSpot™
Client VM 1.7.0) [Windows 7-x86-java]
started
Spewing 0.358074204524305
Did something
Spewing 0.282736311044042
Did something
Spewing 0.682749884231586
Did something
Spewing 0.0601113988185775
1
Did something

C:\Users\Jon\Documents\RubyDev\sandbox>ruby -v trap_sigint.rb
ruby 1.9.3dev (2011-09-04 revision 33179) [i386-mingw32]
started
Spewing 0.45458906220783335
Did something
Spewing 0.017654727547826266
Did something
Spewing 0.632952442589301
Did something
Spewing 0.06243992225919326
1
2

Jon

blog: http://jonforums.github.com/
twitter: @jonforums

“Anyone who can only think of one way to spell a word obviously lacks
imagination.” - Mark Twain

5

On Tue, Sep 6, 2011 at 1:57 PM, Jon [email protected] wrote:

FWIW, on Windows 7 32bit using not-quite-your-snippet
$stopping = falsetrap("SIGINT") { $stopping = true puts "1" # The cal - Pastebin.com I get the following.

Seems the sleep 1 call in the SIGINT handler is confounding JRuby…removing
it works as expected. Not apples-to-apples, but I don’t understand why the
presence of the SIGINT handler sleep seems to impact JRuby.

It’s possible that thread effects are killing the signal handler, in
order to keep the signal-handling thread in the JVM working as
prescribed. Time to open a bug and we can try to investigate.

A possible workaround might be to register a SIGINT handler that does
nothing but tells JRuby to exit (Kernel#exit), with your shutdown
logic in an at_exit hook. Can someone try that?

  • Charlie
6

logic in an at_exit hook. Can someone try that?

  • Charlie

This appears to work for me $stopping = falsetrap("SIGINT") { exit}at_exit do $stopping = true - Pastebin.com

Xavier:

  • does my mod of your original snippet also fail for you?
  • does the workaround also work in your environment?
  • what’s your environment?
  • assuming you’ll file the JIRA bug

Jon

blog: http://jonforums.github.com/
twitter: @jonforums

“Anyone who can only think of one way to spell a word obviously lacks
imagination.” - Mark Twain

7

On Tue, Sep 6, 2011 at 1:05 PM, Xavier S. [email protected] wrote:

On Tue, Sep 6, 2011 at 12:43 PM, Jon [email protected] wrote:

  • does the workaround also work in your environment?

yes. I haven’t tried adapting it to my neo4j example yet, I’ll do that then
file a JIRA bug (regardless of the outcome).

no, workaround did not work in my project :frowning:
for now I’m just trapping USR1 to terminate instead, which is
sub-optimal.

  • assuming you’ll file the JIRA bug

yes, I will. Ball in my court.

http://jira.codehaus.org/browse/JRUBY-6045

Xavier

8

On Tue, Sep 6, 2011 at 12:43 PM, Jon [email protected] wrote:

prescribed. Time to open a bug and we can try to investigate.

  • does my mod of your original snippet also fail for you?
    yes it fails, demonstrating the problem I was having in a simpler
    manner.
  • does the workaround also work in your environment?

yes. I haven’t tried adapting it to my neo4j example yet, I’ll do that
then
file a JIRA bug (regardless of the outcome).

  • what’s your environment?

OSX 10.6.8, jruby 1.6.3

  • assuming you’ll file the JIRA bug

yes, I will. Ball in my court.

Thanks,
Xavier