[zeromq-dev] [zmqpp] Handling of EINTR

[Lindley French]

Just in case anyone really wants EINTR to result in an exception, you could
make that a socket option (zmqpp specific, there's no reason to get libzmq
involved).


On Tue, Jan 14, 2014 at 5:50 AM, Lindley French <lindleyf at gmail.com> wrote:

> Actually, let me strengthen that statement. If you use an exception, your
> code ends up needing to check both of them. It's better to use the return
> code for all common failure cases so user code only needs to check that,
> saving exceptions for when things go so wrong that you probably want the
> program to die anyway.
>
>
> On Tue, Jan 14, 2014 at 5:44 AM, Lindley French <lindleyf at gmail.com>wrote:
>
>> >Polling I also agree should return false, I can't see any good reason it
>> can't be treated the same as a timeout would be, although this does mean an
>> >infinite polling call can return timeout. Would it be worth leaving the
>> exception in for those cases?
>>
>> It makes more sense if you think about it as an indefinite timeout rather
>> than an infinite timeout. No matter whether you return false or throw an
>> exception, users need to be aware that a return from poll() does not always
>> mean something is ready, and code accordingly. In my view the code is
>> cleaner with the return code rather than the exception.
>>
>>
>> On Tue, Jan 14, 2014 at 4:13 AM, Ben Gray <ben at benjamg.com> wrote:
>>
>>> As far as I can see there are three functions where we get EINTR, one of
>>> which we dealt with in a pull request a few days back.
>>>
>>> Receiving messages on a socket currently throws if the first frame of
>>> the message give EINTR, Lindley's proposal that we just return false here
>>> makes the most sense to me. Receive when it gets an EINTR on a frame after
>>> the first currently gets the rest of the message then returns normally, it
>>> was pointed out that this is non-blocking as we know we have the whole
>>> message in zmq so made sense to me.
>>>
>>> Polling I also agree should return false, I can't see any good reason it
>>> can't be treated the same as a timeout would be, although this does mean an
>>> infinite polling call can return timeout. Would it be worth leaving the
>>> exception in for those cases?
>>>
>>> Sending is the other function that can get the EINTR call. In this case
>>> I'd argue we return a false if the first frame gets the EINTR and otherwise
>>> throw an exception as we do currently. My reasoning for this is we will
>>> have left the socket in an invalid state with one or more frames from a
>>> message written to it. The other option would be to send the rest of the
>>> message in non-blocking mode which should be safe as zmq will have told us
>>> on the first part if there is space in the queue, this might be slightly
>>> cleaner but I'd need to make sure the send works as I expected.
>>>
>>>
>>> On 13 January 2014 18:10, Lindley French <lindleyf at gmail.com> wrote:
>>>
>>>> I would but I can't access github from my work. Talking it through is
>>>> my best option in the short term.
>>>>
>>>> > On Jan 13, 2014, at 1:06 PM, Pieter Hintjens <ph at imatix.com> wrote:
>>>> >
>>>> > Handling EINTR with exceptions seems messy. The right way to improve
>>>> > the quality of code sent via pull requests is simply to patch it into
>>>> > shape or delete it if it's offensive (upfront code reviews tend to
>>>> > just introduce friction).
>>>> >
>>>> >> On Mon, Jan 13, 2014 at 6:45 PM, Lindley French <lindleyf at gmail.com>
>>>> wrote:
>>>> >> My zmqpp code has ended up completely littered with clauses like:
>>>> >>
>>>> >>            bool gotit = false;
>>>> >>            try
>>>> >>            {
>>>> >>                gotit = ts.receive(clientId_str,msgin);
>>>> >>            }
>>>> >>            catch (zmqpp::zmq_internal_exception e)
>>>> >>            {
>>>> >>                if (e.zmq_error() != EINTR)
>>>> >>                {
>>>> >>                    throw;
>>>> >>                }
>>>> >>            }
>>>> >>
>>>> >> This is messy, and clearly not ideal because a class type with
>>>> "internal" in
>>>> >> the name shouldn't be necessary for the library user.
>>>> >>
>>>> >> So let's think for a minute. The purpose of EINTR is to ensure
>>>> blocking
>>>> >> calls can't prevent signal handling from working properly. It isn't
>>>> really
>>>> >> an exceptional condition, so is an  exception the appropriate way to
>>>> handle
>>>> >> it? (I'm of the opinion that, unlike Java, exceptions in C++ should
>>>> normally
>>>> >> be reserved for things going seriously wrong.)
>>>> >>
>>>> >> The two places this occurs are poller::poll() and socket::receive().
>>>> Both of
>>>> >> these already return bool. Perhaps we can simply return false in the
>>>> event
>>>> >> if EINTR, instead of throwing? At the very least, this makes sense
>>>> for the
>>>> >> non-blocking version of receive().
>>>> >>
>>>> >> _______________________________________________
>>>> >> 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
>>>> _______________________________________________
>>>> 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/20140114/f48de5a4/attachment.htm>