I assume no-one cares enough to dig into the code and make it work, or pay someone who knows the internals to make it work...
On Fri, Mar 20, 2015 at 4:37 PM, Dylan Cali <[email protected]> wrote: > Hi Pieter, > > Just to follow up, what ever happened to the 'zmq_wait' idea? I see > that mentioned in a few of the discussions I linked, but it doesn't > seem to have ever come to fruition... why not? > > Thanks, > Dylan > > > On Fri, Mar 20, 2015 at 2:49 AM, Pieter Hintjens <[email protected]> wrote: >> There is no "official" behaviour except what's documented in RFCs, so >> bindings come to slow agreement (or not) over time as the case may be. >> Language culture also affects things, e.g. Python may be used more >> often in short-lived scripts where dropping messages in zmq_term is >> unacceptable, while C is used more often in long-running services, >> where blocking on zmq_term is unacceptable. >> >> Of course the right answer would be that the shutdown code in libzmq >> worked properly, though that seems impossible. >> >> -Pieter >> >> On Fri, Mar 20, 2015 at 2:03 AM, Dylan Cali <[email protected]> wrote: >>> After digging into the history a bit, this seems to have been a debate >>> in the community since forever. libzmq had 0 linger in 2.0 [1], moved >>> to -1/infinite linger in 2.1 to match the BSD/POSIX socket API [2], >>> switched to a 2 second linger [3], switched to a 30 second linger [4], >>> and finally switched back to infinite linger [5]. The last one also >>> adds a 'ZMQ_BLOCKY' option as an alternative to setting linger(0) on >>> every socket. >>> >>> So I guess this is a case of different strokes for different folks. >>> It does seem a little odd that bindings hosted under the official >>> zeromq Github would have different semantics, but as long as the >>> linger behavior is clearly documented it's probably not the end of the >>> world. >>> >>> I am curious though what ever happened to the 'zmq_wait' feature >>> proposed in a few of the linked issues/discussions. It seems like >>> that would have eliminated all the ambiguity around linger/blocking >>> behavior: zmq_term terminates immediately, zmq_term_wait(timeout) >>> waits for unsent messages up to an optional timeout, or forever by >>> default. >>> >>> [1] http://thread.gmane.org/gmane.network.zeromq.devel/7760 >>> [2] https://github.com/zeromq/libzmq/issues/126 >>> [3] https://github.com/zeromq/libzmq/issues/1247 >>> [4] https://github.com/zeromq/libzmq/pull/1253 >>> [5] https://github.com/zeromq/libzmq/pull/1258 >>> >>> >>> On Thu, Mar 19, 2015 at 7:36 AM, André Caron <[email protected]> >>> wrote: >>>> FWIW, I've been bitten several times by a close without linger and I now >>>> explicitly set the linger on each socket. It's quite annoying to have to >>>> set `.close(linger=1)` everywhere. It also means I can't use the >>>> "contextlib.closing" context manager to automatically close the socket and >>>> I >>>> have to write my own instead. >>>> >>>> Cheers, >>>> >>>> André >>>> >>>> On Thu, Mar 19, 2015 at 3:53 AM, Pieter Hintjens <[email protected]> wrote: >>>>> >>>>> The sentiment comes from trying and failing to fix the libzmq API on >>>>> several occasions. You'll recall the last time I tried. It's not even >>>>> clear that the linger setting *works* in libzmq, as people have >>>>> reported it simply blocks for N seconds without sending anything. >>>>> However, switching it off has worked very well in CZMQ, for years. >>>>> >>>>> On Thu, Mar 19, 2015 at 2:27 AM, MinRK <[email protected]> wrote: >>>>> > (pyzmq maintainer here) >>>>> > >>>>> > I disagree with the sentiment expressed in the Guide. Either it belongs >>>>> > as >>>>> > the libzmq default behavior itself, or it doesn't. It doesn't make sense >>>>> > to >>>>> > me for language bindings to unanimously disagree with libzmq instead of >>>>> > changing the underlying libzmq behavior. >>>>> > >>>>> > -MinRK >>>>> > >>>>> > On Wed, Mar 18, 2015 at 9:17 PM, Dylan Cali <[email protected]> wrote: >>>>> >> >>>>> >> Hello, >>>>> >> >>>>> >> The zguide states at the end of "Making a Clean Exit": >>>>> >> >>>>> >>> you need to shut down each socket that has ongoing requests. The >>>>> >>> proper >>>>> >>> way is to set a low LINGER value (1 second), and then close the >>>>> >>> socket. If >>>>> >>> your language binding doesn't do this for you automatically when you >>>>> >>> destroy >>>>> >>> a context, I'd suggest sending a patch. >>>>> >>> >>>>> >>> ... >>>>> >>> >>>>> >>> Voila! It's complex and painful enough that any language binding >>>>> >>> author >>>>> >>> worth his or her salt will do this automatically and make the socket >>>>> >>> closing >>>>> >>> dance unnecessary. >>>>> >> >>>>> >> >>>>> >> Yet I noticed the pyzmq bindings do not seem to follow this convention >>>>> >> and >>>>> >> scripts that do not explicitly set linger themselves hang. The pyzmq >>>>> >> devs >>>>> >> closed this as a non-issue: >>>>> >> >>>>> >> https://github.com/zeromq/pyzmq/issues/102 >>>>> >> >>>>> >> Conversely, both the czmq and jzmq bindings do set a low linger: >>>>> >> >>>>> >> https://github.com/zeromq/czmq/issues/116 >>>>> >> http://git.io/hBaf >>>>> >> >>>>> >> So should this be considered a bug in pyzmq, and as a bindings author >>>>> >> should I follow the convention of setting a low linger? >>>>> >> >>>>> >> Thanks much, >>>>> >> Dylan >>>>> >> >>>>> >> >>>>> >> >>>>> >> _______________________________________________ >>>>> >> 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 >> _______________________________________________ >> 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
