From: Eric Wong Date: 2018-07-08T06:52:36+00:00 Subject: [ruby-core:87874] Re: [Ruby trunk Misc#14901] [PATCH] do not block SIGCHLD in normal Ruby Threads takashikkbn@gmail.com wrote: > I have not completely read your patch for [Bug #14867] yet, so > let me ask some questions to understand the context. > > > I blocked SIGCHLD in normal Ruby Threads for [Bug #14867] > > In the current trunk, in what kind of situation are normal > Ruby Threads "blocked" by SIGCHLD? Are they blocked by > default, or only during Process.waitall and its families are > invoked? > > And also, does the "blocked" mean interruption by a signal > handler for SIGCHLD? Ah, you seem to misunderstand, I suppose the terminology is confusing :x 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. It is analogous to ec->interrupt_mask. 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. > If you're going to remove the Timer thread from normal Ruby > execution, I'm in favor of handling signals with MJIT thread > for simplicity, if it's not so hard to implement it in MJIT > thread. Right now, MJIT thread can already receive signals and run signal.c::sighandler (just like any other thread). So maybe there's no need to do anything special, just let any thread handle any signals as before. Another problem is mjit thread (or timer thread) doesn't always run, due to resource limitations or MJIT.pause, and we'd still need signal handling in those cases. Unsubscribe: