Project

General

Profile

Actions

Bug #10595

closed

interrupts not handled while finalizers running

Added by normalperson (Eric Wong) almost 10 years ago. Updated almost 10 years ago.

Status:
Closed
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) almost 10 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) almost 10 years ago

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) almost 10 years ago

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

Actions

Also available in: Atom PDF

Like0
Like0Like0Like0