Bug #10595
closedinterrupts not handled while finalizers running
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 11 years ago
          Updated by nobu (Nobuyoshi Nakada) almost 11 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 11 years ago
          Updated by normalperson (Eric Wong) almost 11 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) almost 11 years ago
          Updated by nobu (Nobuyoshi Nakada) almost 11 years ago
          
          
        
        
      
      Yes, but interruptions of finalizers could cause serious undesirable results.