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

[Dylan Cali]

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