[zeromq-dev] [patch] handle SIGPIPE

Brian Bloniarz bmb at athenacr.com
Wed Jul 7 17:12:53 CEST 2010

On 07/07/2010 03:55 AM, Steven McCoy wrote:
> On 7 July 2010 15:03, Martin Lucina <mato at kotelna.sk
> <mailto:mato at kotelna.sk>> wrote:
>     I don't have the code handy right now, look for the call to
>     pthread_sigmask(). The signal mask is cleared for all 0MQ I/O threads,
>     so they will not get any signals (excepting SIGSEGV, etc.)
>  #if !defined ZMQ_HAVE_OPENVMS
>     //  Following code will guarantee more predictable latecnies as it'll
>     //  disallow any signal handling in the I/O thread.
>     sigset_t signal_set;
>     int rc = sigfillset (&signal_set);
>     errno_assert (rc == 0);
>     rc = pthread_sigmask (SIG_BLOCK, &signal_set, NULL);
>     errno_assert (rc == 0);
> #endif
> So the I/O threads which are created by ZeroMQ explicitly ignore all
> signals but SIGKILL and SIGSTOP.  In this case ignore means that the
> default action is not taken.
> http://www.kernel.org/doc/man-pages/online/pages/man3/pthread_sigmask.3.html
> http://www.kernel.org/doc/man-pages/online/pages/man2/sigprocmask.2.html
> With the default actions listed in signal(7), i.e. term on most defined
> signals, or stops the actions defined by the calling thread being inherited.
> http://www.kernel.org/doc/man-pages/online/pages/man2/sigprocmask.2.html

I think the wording here is confusing, but the conclusion is correct.
Here's my attempt to clarify:

ZeroMQ does not ignore signals, it sets its threads to block them.
This means that any signal which is caused by the thread will be:
1) set as *pending* for the thread, if it is a thread-directed signal
2) sent to another thread in the process, if it is a process-directed signal

Like Martin is getting at, getting SIGPIPE from send() is a thread-directed
signal so (1) will happen; that's also what I think from looking at
Open Group Base Specifications 2.10.14

So I agree that the patch shouldn't be necessary unless some OSes
don't follow posix.

As an aside, the SIGPIPE is simply set to pending, not ignored; if
the ZeroMQ thread ever restores the sigmask to unblocked, the process
will be killed.

More information about the zeromq-dev mailing list