Hi all,
> First, to summarize to others who were not part of the IRC discussion
> yesterday (especially binding maintainers, but anyone doing signal handling
> in a 0MQ application, take note!) what the "EINTR issue" is:
To summarise Mato's discussion, the problem is that most interpreted
languages ignore Ctrl+C while stuck in 0MQ blocking call such as 'recv'.
> Currently 0MQ API calls do not return with (-1, errno=EINTR) if a system
> call being called by the 0MQ API returns EINTR. This is due to a historical
> decision by Martin Sustrik.
I am expected to admit that I'm an idiot here. So here it goes:
I'm an idiot.
> [Thanks to Martin Sustrik for documenting this precise race condition].
A short summary of the proposed solution: Ctrl+C would work in 99% of
cases. Still, it won't work occasionally. In such a case, press Ctrl+C
once more.
> Correct, except for the caveat in point f) above.
To summarise: No, there's no way to make this work in 100% of cases.
POSIX API is broken. Sorry, folks.
> For 2.0.x, I'm not sure. The problem is it will break code that does not
> expect API calls to return EINTR, *if and only if* that application does
> get a signal. Given that most of the time the only thing signals are used
> for is telling an application to terminate, I would not expect the effect
> to be fatal.
Actually, original decision to ignore EINTR was a user request!
Thus, there are applications out there that depend on zmq_* functions
not returning EINTR.
I don't think there's a way to accommodate both existing install base
and new apps written with stable branch (currently 2.0.8). I hate to say
it, but the fix will have to go to 2.1. Even that is not completely
kosher. Backwards incompatible API change shoud go into new _major_ version.
Maybe it's time to rethink the stability guidelines?
Martin
_______________________________________________
zeromq-dev mailing list
[email protected]
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
