JRuby

tearDown() is not executed if the executon is terminated via Control-C

Details

  • Type: Bug Bug
  • Status: Resolved Resolved
  • Priority: Major Major
  • Resolution: Won't Fix
  • Affects Version/s: JRuby 1.4
  • Fix Version/s: None
  • Component/s: Core Classes/Modules
  • Labels:
    None
  • Number of attachments :
    0

Description

Not executing Ruby.tearDown() leads to some undesirable effets: at_exit blocks are not executed, various registered finalizers are not executed as well.

Here's an example:

jruby -e "at_exit {p 'AT_EXIT'}; puts 'Press Control-C'; sleep(10)"

JRuby prints "Press Control-C", and when it's pressed, AT_EXIT is not printed. at_exit blocks are just not executed at all.

For MRI, AT_EXIT is printed as expected.

Maybe, the solution for this could be to register a signal handler for Control-C and then execute tearDown().

Issue Links

This issue is duplicated by:
JRUBY-6410 at_exit blocks do not run when a process is terminated via a SIGINT Major Resolved
JRUBY-4610 MRI inconsistency: JRuby doesn't appear to run 'ensure' code when it receives a kill signal. Major Closed

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Charles Oliver Nutter added a comment -

I'm inclined to mark this "not a bug" since it's a behavioral difference for us running on the JVM.

As you know, the JVM hooks ^C to do a full, hard JVM shutdown. We could steal that hook and use it for raising Interrupt, as MRI does (which would cause a normal sequence of ensures and exit hooks to fire), but if a program cause Interrupt or froze up in some other way, we woule potentially prevent ^C from doing the hard shutdown most JVM users expect.

It's also easy to work around; if you intend to have a program that wants to receive and handle ^C, you can just hook the signal yourself and raise Interrupt in the main thread:

~/projects/jruby ➔ cat interrupt.rb 
trap 'INT' do
  Thread.main.raise Interrupt
end

sleep

~/projects/jruby ➔ jruby interrupt.rb 
^Cinterrupt.rb:5: Interrupt (Interrupt)
Show
Charles Oliver Nutter added a comment - I'm inclined to mark this "not a bug" since it's a behavioral difference for us running on the JVM. As you know, the JVM hooks ^C to do a full, hard JVM shutdown. We could steal that hook and use it for raising Interrupt, as MRI does (which would cause a normal sequence of ensures and exit hooks to fire), but if a program cause Interrupt or froze up in some other way, we woule potentially prevent ^C from doing the hard shutdown most JVM users expect. It's also easy to work around; if you intend to have a program that wants to receive and handle ^C, you can just hook the signal yourself and raise Interrupt in the main thread: 
~/projects/jruby ➔ cat interrupt.rb 
trap 'INT' do
  Thread.main.raise Interrupt
end

sleep

~/projects/jruby ➔ jruby interrupt.rb 
^Cinterrupt.rb:5: Interrupt (Interrupt)
Hide
Permalink
Charles Oliver Nutter added a comment - - edited

Marking as WONTFIX. The JVM itself hooks SIGINT, and we will not interfere with that. The unexpected consequences of a non-Ctrl-C-able JVM outweigh the benefit of hooking SIGINT for all the cases MRI hooks it.

Show
Charles Oliver Nutter added a comment - - edited Marking as WONTFIX. The JVM itself hooks SIGINT, and we will not interfere with that. The unexpected consequences of a non-Ctrl-C-able JVM outweigh the benefit of hooking SIGINT for all the cases MRI hooks it.

People

Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved:
Atlassian JIRA (v4.4.3#663-r165197) | Report a problem
Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.