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

Michael Compton michael.compton at littleedge.co.uk
Tue Mar 15 20:56:53 CET 2011

On Tue, 2011-03-15 at 13:28 +0100, Martin Lucina wrote:
> 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?
The GC uses signals in its operation, these cause the system calls to
return, I doubled checked this by running with no GC, there was no

> > "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).
My solution, thanks to a suggestion from Pieter, is to catch SIGINT and
SIGTERM and exit the program. 

If I don't do this clrzmq2 will be a pain for users with Mono on POSIX
platforms, they will be forced to deal with this exception all the time;
the GC making it way too common of an occurrence.

> -mato
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev


More information about the zeromq-dev mailing list