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
