[zeromq-dev] "cython inline checkrc" change in PyZMQ 13.0.0 changes handling of EINTR?
Felipe Cruz
felipecruz at loogica.net
Tue Mar 12 00:17:11 CET 2013
Great!
I didn't noticed PR 338.. So it's really fully fixed in master.
2013/3/11 MinRK <benjaminrk at gmail.com>
> To further clarify, there are two cases:
>
> 1. no sigint handler registered - ^C absolutely should result in
> KeyboardInterrupt. This behavior is intended, and has not changed since
> 2.1.9.
> 2. sigint handler registered - in this case, KeyboardInterrupt should
> *not* be raised, and the regular ZMQError(EINTR) should happen. This was
> broken in 13.0.0, but is fixed in master.
>
> 13.0 was a big release, and there are unsurprisingly a few bugs. There
> will be a bugfix release around 30 days after the original (about two weeks
> from now).
>
> -MinRK
>
>
> On Mon, Mar 11, 2013 at 2:16 PM, Min RK <benjaminrk at gmail.com> wrote:
>
>>
>>
>> On Mar 11, 2013, at 13:13, Jonathan Kamens <jkamens at quantopian.com>
>> wrote:
>>
>> Greetings,
>>
>> With PyZMQ versions prior to 13.0.0, we were running into problems with
>> certain PyZMQ calls getting interrupted by restartable signals (e.g.,
>> SIGALRM) used by our application. We fixed this problem like this:
>>
>> while True:
>> try:
>> self.context.term()
>> except zmq.ZMQError as exc:
>> if exc.errno == EINTR:
>> log.info('zmq_term interrupted by signal,
>> restarting')
>> else:
>> log.exception('Error terminating ZMQ context')
>> raise
>> except BaseException as exc:
>> log.exception('Error terminating ZMQ context')
>> raise
>> else:
>> break
>>
>> Note that 0MQ allows term() to be restarted when it gets EINTR<http://api.zeromq.org/2-1:zmq-term#toc4>
>> .
>>
>> This worked just fine, but has stopped working in PyZMQ 13.0.0. Now,
>> instead of a ZMQError with errno set to EINTR, we are getting a
>> KeyboardInterrupt exception. I think this commit to PyZMQ<https://github.com/zeromq/pyzmq/commit/3959e4515f86db11f660738df5d36f62478c39e2>is the cause.
>>
>> Questions:
>>
>> 1. Was this change in behavior intentional? If so, it probably should
>> be documented in the release notes.
>> 2. Am I understanding correctly that what needs to be done to fix the
>> problem in my app is to do "except KeyboardInterrupt" instead of "except
>> zmq.ZMQError as exc" and not bother to check errno?
>>
>> Thanks in advance for any help you can provide.
>>
>>
>> This was not intentional, and is fixed in master. There should only be a
>> difference in behavior if you have non-default signal handler registered.
>>
>>
>> Regards,
>>
>> Jonathan Kamens
>>
>> _______________________________________________
>> zeromq-dev mailing list
>> zeromq-dev at lists.zeromq.org
>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>
>>
>
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20130311/31657b70/attachment.htm>
More information about the zeromq-dev
mailing list