Issue #14901 has been updated by k0kubun (Takashi Kokubun).


> In this context, "blocking" mean disabling interrupts using pthread_sigmask/sigprocmask. As in: blocking signals from being delivered to threads. Not blocking the threads themselves.

Oh I see. Thanks for the clarification.

> Before #14867: any thread can be interrupted by any signal at any time; aside from around fork/vfork/execve.
> After #14897: any thread can receive non-SIGCHLD signals, only timer-thread sees SIGCHLD
> This patch will restore pre-#14867 behavior.
> My reasoning for this patch is that if any code is found broken by SIGCHLD from MJIT; it will ALSO (sooner or later) be found broken if hit by other signals. So the current disabling of SIGCHLD is just a hack to get tests to pass.

So these 2 issues ("OpenSSL::PKey::*.new", test/-ext-/gvl/test_last_thread.rb) are (or should be) out of scope of [Bug #14867], which are still not resolved in a correct way, and this patch is going to remove the workaround to let them succeed. I can understand that direction.

If you already know they fail after committing the patch and they're going to be resolved separately, please skip them for now when RubyVM::MJIT.enabled?.

----------------------------------------
Misc #14901: [PATCH] do not block SIGCHLD in normal Ruby Threads
https://bugs.ruby-lang.org/issues/14901#change-72888

* Author: normalperson (Eric Wong)
* Status: Open
* Priority: Normal
* Assignee: k0kubun (Takashi Kokubun)
----------------------------------------
@k0kubun: any opinions on this?  Thanks.

```
I blocked SIGCHLD in normal Ruby Threads for [Bug #14867]
because I noticed at least two places which could not deal
with spurious wakeups in our test suite.

I also want to get rid of timer-thread due to resource
limitations [ruby-core:87773].  MJIT causes many SIGCHLD signals
so I found the following problems with cppflags=-DMJIT_FORCE_ENABLE=1

* OpenSSL::PKey::*.new does not resume on handle signals.
  rhenium acknowledged the problem and it should be in trunk soon:
  https://bugs.ruby-lang.org/issues/14882

* test/-ext-/gvl/test_last_thread.rb does not handle spurious
  wakeups.  Original report is in Japanese:
  https://bugs.ruby-lang.org/issues/11237
  I don't think it's a realistic expectation for code to be
  unable to deal with spurious wakeups.

One alternative could be to handle signals with MJIT thread
when MJIT is enabled, or to lazy-spawn timer thread to handle
signals when MJIT is enabled (MJIT + gcc requires a lot of
resources, anyways).
```


---Files--------------------------------
0001-do-not-block-SIGCHLD-in-normal-Ruby-Threads.patch (2.5 KB)


-- 
https://bugs.ruby-lang.org/

Unsubscribe: <mailto:ruby-core-request / ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>