Project

General

Profile

Bug #10595

interrupts not handled while finalizers running

Added by normalperson (Eric Wong) about 5 years ago. Updated about 5 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Target version:
ruby -v:
trunk
[ruby-core:66825]

Description

Originally noted in [ruby-core:66635]

Trying to Ctrl-C something like the following loop is not always successful:

f = proc { 1000.times {} }
loop do
  ObjectSpace.define_finalizer(Object.new, f)
end

The Interrupt is created and raised, but lost during the postponed
job processing (rb_postponed_job_flush).

Trying to mask out all interrupt flags (instead of just
th->interrupt_mask |= POSTPONED_JOB_INTERRUPT_MASK) allows the
interrupt to be handled, but this is not suitable for expensive
finalizers.

So I haven't figured out how to fix this, yet... Help appreciated, thanks.

Updated by nobu (Nobuyoshi Nakada) about 5 years ago

  • Status changed from Open to Closed
  • % Done changed from 0 to 100

Applied in changeset r48829.


vm_trace.c: defer interrupts while postponed jobs

  • vm_trace.c (rb_postponed_job_flush): mask signal trap interrupt too to defer handling after finalizers finished. [ruby-core:66825] [Bug #10595]

Updated by normalperson (Eric Wong) about 5 years ago

nobu@ruby-lang.org wrote:

vm_trace.c: defer interrupts while postponed jobs

  • vm_trace.c (rb_postponed_job_flush): mask signal trap interrupt too to defer handling after finalizers finished. [ruby-core:66825] [Bug #10595]

Sorry, I tried something like this but it's not effective if the
finalizer has an expensive (or infinite) loop.

I suppose it's better than nothing and finalizers should not
be expensive...

Updated by nobu (Nobuyoshi Nakada) about 5 years ago

Yes, but interruptions of finalizers could cause serious undesirable results.

Also available in: Atom PDF