[zeromq-dev] Signal handling in blocking zmq_recv

[Chris Wong]

Martin,

If pthread_sigmask() is used to block any signals from interrupting the I/O thread, how do one unblock a blocked zmq_recv?  What's the alternative if we need to do so?

Chris

On Mar 9, 2010, at 12:43 PM, Martin Lucina wrote:

> Brian,
> 
> ellisonbg at gmail.com said:
>> This example is helpful.
>> 
>>> http://github.com/mato/zeromq-examples/blob/master/zmq-camera.c
> 
> Glad the example is useful...
> 
>> Based on the information here:
>> 
>> http://docs.python.org/library/signal.html
>> 
>> I think it might be possible to handle this in python with 2 app
>> threads.  But because Python only handles signals in the main thread,
>> it would require having the main thread just do the signal handling.
>> This is on my list of things to explore.
> 
> OK, it's been some time since I looked at the signal handling mess.
> 
> First, 0MQ does not change any signal handlers on any application threads,
> ever. The only signal-related calls in 0MQ are in src/thread.cpp and that
> is to use pthread_sigmask() to block any signals from interrupting 0MQ I/O
> threads.
> 
> The reason zmq-camera.c uses an explicit signal handling thread with a
> sigwait() loop is that as far as I'm aware this is the *only* way to
> reliably handle signals in a multithreaded program on POSIX platforms. Any
> other option seems to result in various different non-deterministic
> behaviours.
> 
> The problem with Python (or Ruby, or any other) language runtime is that as
> far as I know they don't neccessarily do this. Or if they do, they're doing
> something *else* that's somehow interacting with 0MQ's use of
> pthread_sigmask(), not that that should ever happen. I spent a day or so
> investigating what it is that actually breaks signal handling with 0MQ and
> Python and wound up none the wiser.
> 
> So, good luck, if you do discover what the problem is that would be
> amazing!
> 
> Cheers,
> 
> -mato