I'm not even going to _suggest_ a setctxopt() that lets you decide on
the fly :-)
setctxopt(ctx, ZMQ_SIGRET, sigvec[], unsigned num_sigs); // not a
pun on "cigarette"
Then the default would simply change between version 2.x and 3.x ... :-(
I haven't looked at how deep you have to go to get the behavior right.
On Sep 3, 2010, at 8:29 AM, Martin Sustrik wrote:
> On 09/03/2010 01:54 PM, Pieter Hintjens wrote:
>
>> However - Martin, you can confirm - if this change actually breaks
>> existing code (i.e. it will not run and cannot trivially be changed)
>> then we should not make it in 2.0.9.
>
> Yes. It does. The most obvious way to do error handling (at least to
> me)
> if to check for EAGAIN and ETERM and handle those is special ways.
> Then
> assert on any other error.
>
> Given that "any other error" would now include EINTR, the application
> would fail because of some innocent signal.
>
>> Looking at the zeromq-dev archive discussions on EINTR it's not clear
>> who asked for this to be ignored...
>
> It was a customer so the discussion wasn't public. The problem IIRC
> was
> something like that they were using profiler which used signals to
> interrupt the application (and to measure the profiling statistics)
> which in turn caused 0MQ's blocking calls to exit with EINTR all the
> time.
>
> My intuitive feeling about stability guarantees is:
>
> New patch: I can install it in the production without breaking my
> apps.
>
> New minor version: It will be able to build my app, however, I should
> check the documentation to make sure that subtle changes to the
> semantics don't affect my code.
>
> New major version: No guarantees. Presumably, my application won't
> even
> build.
>
> Martin
> _______________________________________________
> zeromq-dev mailing list
> [email protected]
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
_______________________________________________
zeromq-dev mailing list
[email protected]
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
