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
