[zeromq-dev] [zmqpp] Handling of EINTR

[Ben Gray]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20140114/111d55c9/attachment.htm>