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 <[email protected]> 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 <[email protected]>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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >>>> 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 >>>> >> [email protected] >>>> >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev >>>> > _______________________________________________ >>>> > 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 >>>> >>> >>> >>> _______________________________________________ >>> 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
