[zeromq-dev] [zmqpp] Handling of EINTR

[Lindley French]

>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/a83b5125/attachment.htm>