c++ - 线程，信号和子处理: What a world. ..什么世界

所以我有一个有趣的设计问题。我正在SLES 9+ Linux，内核2.6+上工作，并且具有充当RPC客户端的多线程应用程序。这样做的想法是使处理请求的线程很少。这样的请求之一是作为子进程开始“工作”。

现在，我遇到的问题是设置适当的信号处理程序来处理各种信号。我所做的是设置了另一个线程，用于处理sigwait()状态的信号，同时阻止其他线程中的所有相关信号。想法是，该过程的所有信号都应传递到信号处理线程，而其余线程仅应担心传入的处理请求。

除了那些烂 child 之外，所有这些工作都很棒，他们总是将飞盘扔到我的后院，在我的草坪上践踏。但是，总的来说，我的信号处理线程没有收到SIGCHLD信号。关于这里发生的事情，我最好的猜测是，因为信号处理线程不是产生子进程的线程，所以它不是接收SIGCHLD的线程，而是执行该任务的我的工作线程。

关于我的问题:

我对SIGCHLD不能进入我的信号处理程序线程感到疯狂吗？

如果我不疯(我知道这是一个难题)，您将如何解决这个小问题？目前，我正在为在所有线程上设置的SIGCHLD设置一个非常简单的信号处理程序，该信号处理程序只是将信号作为SIGUSR2信号重新发送给进程组，该进程组在所有线程中被阻塞，从而允许信号处理线程。这似乎可行，但是我不禁会认为我丢失了某些东西，或者有更好的方法来处理此问题……他，明白了，处理了……好吧，我现在就停止

As per David Schwartz request SLES9: NPTL 2.3.5, SLES10: NPTL2.4

最佳答案

(编辑:因为我看不懂，并且您已经在执行正确的pthread_sigmask调用...。)

在2.6内核中，将SIGCHLD设置为ignore/SIG_IGN时，内核将为您获取子进程。听起来好像是否为信号处理线程设置了SIGCHLD的特定处理程序，以避免将SIGCHLD设置为SIG_IGN/SIG_DFL。

编辑(从评论):
我认为您遇到了麻烦。如果在生成子代的线程中将其保留为SIG_IGN，则内核甚至不会发送SIGCHLD。但是，如果将其设置为可处理，则将调用您的处理程序。我认为，如果您设置了处理程序，但仍然在pthread_sigmask中阻止了信号，则信号将被传递到没有信号被阻止的线程(您的sigwait线程)。