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