[zeromq-dev] Signal handling in blocking zmq_recv

Martin Lucina mato at kotelna.sk
Wed Mar 10 23:40:42 CET 2010


ellisonbg at gmail.com said:
> > What you're saying is that the Python signal handler receives the signal,
> > queues some kind of internal flag indicating "a signal was received" but
> > doesn't actually *act on* the signal until the 0MQ C++ code returns to the
> > Python binding, and the Python binding returns control to the Python
> > interpreter.
> >
> > Do I understand you correctly?
> Yes, that is my understanding of what Python is doing.

I thought of removing just the pthread_sigmask() calls from 0MQ but that
actually has nothing to do with the problem, since the zmq_recv()
implementation does a poll() (or equivalent) when blocking and will
explicitly restart a system call if it gets EINTR back.

The rationale behind this behaviour is that we consider EINTR a historic
UNIX artifact we didn't want to reproduce, therefore you will *never* get
EINTR back from any 0MQ library function.

Unfortunately I don't see any straightforward solution to your problem.
Reintroducing EINTR into 0MQ just seems horrible :-(


More information about the zeromq-dev mailing list