Bug #17587: Segmentation fault with ractors and unix signals

• Status: Rejected
• Assignee: ko1 (Koichi Sasada)
• Target version: -
• ruby -v: ruby 3.0.0p0 (2020-12-25 revision 95aff21468) [x86_64-darwin19]
• Backport: 2.5: UNKNOWN, 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN

[mweitzel (Matthew Weitzel)]

Segmentation fault when trapping signals and using a Ractor.

Can be reproduced by running the following

Ractor.new do
  Signal.trap('INT') do
    Ractor.yield("yoo hoO! big summer blowout")
  end
  `kill -2 #{$$}`
  `kill -2 #{$$}`
  `kill -2 #{$$}`
end.take

[ko1 (Koichi Sasada)]

• Assignee set to ko1 (Koichi Sasada)

current master is stuck.
I'll check it.

[wanabe (_ wanabe)]

The current behavior of stacking appears to be as expected.

The registered signal handler is called from the main thread. https://git.ruby-lang.org/ruby.git/tree/thread.c?id=947d93b715436b13eefa39f87737bdad3c1f870a#n2430
Ractor.yield in the main thread must cause stuck because there are no Ractor to take it in parallel.
In addition, signals are basically ignored in the signal handler, because of interrupt_mask. https://bugs.ruby-lang.org/issues/6009
For example, Signal.trap("USR2") do sleep end; Process.kill(:USR2, $$) can make ruby stuck.

I guess this is normal behavior that has nothing to do with Ractor.
(However, there is still room for consideration of safe behavior when a signal is received in a signal handler.)

[hsbt (Hiroshi SHIBATA)]

• Status changed from Open to Assigned

[ko1 (Koichi Sasada)]

• Status changed from Assigned to Rejected

as @wanabe (_ wanabe) san described, it is an expected behavior.
(I'm not sure why I prohibited trap in Ractor...)