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

[Pieter Hintjens]

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