On Tue, 2011-03-15 at 13:28 +0100, Martin Lucina wrote: > michael.comp...@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 EINTR.
> > > "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@lists.zeromq.org > http://lists.zeromq.org/mailman/listinfo/zeromq-dev Cheers, Michael _______________________________________________ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
