[zeromq-dev] Are bindings supposed to set linger on implicit close/destroy?

Dylan Cali calid1984 at gmail.com
Fri Mar 20 02:03:26 CET 2015


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 <andre.l.caron at gmail.com> 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 <ph at imatix.com> 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 <benjaminrk at gmail.com> 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 <calid1984 at gmail.com> 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
>> >> 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
>
>
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>



More information about the zeromq-dev mailing list