Brian, [email protected] 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 _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
