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

Fri Mar 20 18:53:24 CET 2015

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 <calid1984 at gmail.com> 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 <ph at imatix.com> 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 <calid1984 at gmail.com> 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 <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
>>>>
>>> _______________________________________________
>>> 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