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: <mailto:ruby-core-request / ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>