[zeromq-dev] Interruptted System Calls, EINTR, and more about POSIX signals than I ever wanted to know

[Martin Lucina]

michael.compton at littleedge.co.uk said:
> Hi all,
> 
> Sorry for the long subject name, I'm going to try and keep this short
> because it gives me a headache, hehe.
> 
> This is some what connected to the following from the mailing list:
> http://lists.zeromq.org/pipermail/zeromq-dev/2010-September/005822.html

That's an accurate summary of the problems involved.

> While developing the clrzmq2 and using it on POSIX platforms with MONO,
> I have came across some bothersome behaviour with blocking syscalls and
> signals. Quite frequently the blocking calls, such as Recv and Poll,
> would return -1 with ERRNO 4 (Interrupted System Call). 
> 
> The likely culprit for these signals is the Mono GC, though it has
> handlers there to catch them. According to what I have learnt, blocking
> syscalls will first return -1 when there is a signal and then the
> handler will be invoked.

Why would GC have anything to do with interrupting blocking system calls?

> "When a system call is slow and a signal arrives while it was blocked,
> waiting for something, the call is aborted and returns -EINTR, so that
> the library function will return -1 and set errno to EINTR. Just before
> the system call returns, the user program's signal handler is called."
> 
> Source 4.5 here: http://www.win.tue.nl/~aeb/linux/lk/lk-4.html
> 
> But the story also gets even more interesting, there is an SA_RESTART
> flag which handlers can set so that the syscall will be continued after
> the signal is handled, which incidentally the Mono GC sets, the problem
> is that the SA_RESTART does not restart all syscall and is at best a
> hint; it is also undocumented which syscalls it will restart.

SA_RESTART is a non-portable mess, as you write yourself it cannot be
relied upon.

> So now I am left with the dilemma of what to do with these interruptions
> to syscalls, do I try to handle it in the clrzmq2 binding by attempting
> the call again, or do I let it bubble up to the user for them to deal
> with. 

I would advise against any kind of auto-retry mechanism in clrzmq2; if you
don't bubble up the EINTR to the user you will lose any ability to
interrupt blocking zmq calls. This will result in the "Ctrl-C is not
working" scenario which we had with zmq 2.0 where we did precisely this
(ignored EINTR from syscalls).

-mato