Is there any guarantee that you cannot get EINTR if the packet has been transmitted?

If you retry sending the packet, then it is sent TWICE, which may confuse the other end.

Or give up on portability and use some API that solves this proble, like, say, Solaris event ports (just post an event from the handler, or put the port into alert mode from the handler).

As for condition variables… if only pthread_mutex_lock() were async-signal-safe… then you could acquire the mutex, signal/broadcast on the cv, and drop the lock. But it's not, so you can't. What you can do is resort to having a thread waiting for events on a pipe written to by the signal handler (see above!) then have that thread signal/broadcast on you condition variable.

See? The trick is to transmogrify async signals into events that you can wait for with traditional async I/O APIs.

Still, it doesn't work for libraries. Unless, of course, ZeroMQ would expose zmq_precv (…, const sigset_t *sigmask) in addition to standard zmq_recv.

1. block signals
2. check if signal is pending (this is atomic because signals are blocked)
3. pselect()
5. recv()
6. if we need more data, goto 2 (yes, 2, so we don't miss a signal)
7. else unblock signals and return data to user

It can never happen that a signal is received and we wait indefinitely in pselect().

However, consider this example (pretty common ZeroMQ use case): User calls zmq_recv (a blocking function) to get some work. Then he processes the work. With the pselect solution, the program would be interruptible while waiting for a message (say 0.1 sec) but not interruptible while processing the work (say 1 hour).

The reason that pselect() is needed is that if one wants to wait for either a signal or for a file descriptor to become ready, then an atomic test is needed to prevent race conditions. (Suppose the signal handler sets a global flag and returns. Then a test of this global flag followed by a call of select() could hang indefinitely if the signal arrived just after the test but just before the call. By contrast, pselect() allows one to first block signals, handle the signals that have come in, then call pselect() with the desired sigmask, avoiding the race.

 set file descriptor to non-blocking; sigprocmask() to block SIGINT; if (stop) { // handle it } while (1) { pselect() with sigmask argument which doesn't block SIGINT; if (stop) { // handle it } recv(); } 

The magic here is that signals are blocked except during the pselect(), and pselect() atomically unblocks them when it's called and blocks them when it returns. As a result, the signal handler can only execute during the pselect(), so it is safe to only check the flag after pselect() returns.