[zeromq-dev] zmq_ctx_term vs zmq_ctx_destroy vs zmq_ctx_shutdown

[MinRK]

On Sun, Jun 15, 2014 at 11:55 AM, Indradhanush Gupta <
indradhanush.gupta at gmail.com> wrote:

>
>
>
> On Mon, Jun 16, 2014 at 12:17 AM, MinRK <benjaminrk at gmail.com> wrote:
>
>> To add further confusion, PyZMQ distinguishes term from destroy (pyzmq
>> used the term ‘destroy’ before zmq did).
>>
>> In pyzmq, ctx.term just calls the underlying libzmq zmq_ctx_term (née
>> zmq_term) function, which blocks until all sockets are closed.
>> ctx.destroy, on the other hand, closes all sockets prior to calling
>> term. czmq has a similar behavior for destroy. After these destroy
>> behaviors were established, libzmq added a zmq_ctx_destroy function, but
>> just as a rename of zmq_term, which causes confusion like this, hence
>> the change replacing zmq_ctx_destroy with the less confusing zmq_ctx_term
>> .
>>
> But I still don't get why zmq.Context.term() blocks while
> zmq.Context.destroy() returns immediately. I am stopping my reactor loop
> and closing down my open sockets first.
>

If term blocks and destroy doesn't, that means that you still have open
sockets or unsent messages with LINGER=-1. How are you closing your
sockets? Can you provide a code sample that reproduces the behavior you are
seeing?

-MinRK



>
>
>> -MinRK
>> ​
>>
>>
>> On Sun, Jun 15, 2014 at 6:03 AM, Pieter Hintjens <ph at imatix.com> wrote:
>>
>>> zmq_term/zmq_init are an older deprecated API. We switched to a more
>>> consistent model for the API in 3.2, so zmq_ctx_xxx for all methods
>>> that work with contexts, like zmq_msg_xxx for all methods that work on
>>> messages.
>>>
>>> zmq_ctx_destroy was the initial choice for the termination method.
>>> However people pointed out that the context isn't actually destroyed,
>>> it's terminated, so we added _term() as a synonym. To be honest I'm
>>> not keen on _term() as it seems inconsistent for no benefit. We
>>> destroy sockets and contexts asynchronously... I'd prefer _destroy().
>>>
>>> More usefully, we later added _shutdown() method that stops the
>>> context but leaves it in existence; this allows a two-stage shutdown,
>>> with signals being sent to all sockets waiting on blocking operations,
>>> and then allowing the app to call zmq_ctx_destroy/term when wanted.
>>>
>>> -Pieter
>>>
>>> On Sat, Jun 14, 2014 at 3:34 PM, Indradhanush Gupta
>>> <indradhanush.gupta at gmail.com> wrote:
>>> > Hello,
>>> >
>>> > I consulted the docs for zmq_ctx_term and zmq_ctx_destroy, in the API
>>> > version 4.0 and it appears to be both have the same description. What
>>> is the
>>> > difference between the two?
>>> > I'm using pyzmq, by the way.
>>> >
>>> > When I called zmq.Context.term() the call blocks indefinitely, while
>>> > zmq.Context.destroy() returns immediately. I am shutting down my
>>> IOLoop,
>>> > then closing all open sockets by hand and only then calling one of the
>>> > above.
>>> >
>>> > What is the difference between the two calls? Also, it appears
>>> > zmq_ctx_destroy is going to be deprecated according to the 4.1 dev API
>>> docs.
>>> > Why is term() blocking while destroy() doesn't?
>>> >
>>> > I'm also confused as to when should I call shutdown, destroy or term?
>>> >
>>> > If it helps, I have not set any LINGER option on any of the sockets.
>>> >
>>> > Thanks,
>>> > --
>>> > Indradhanush Gupta
>>> > (dhanush on irc)
>>> >
>>> >
>>> > _______________________________________________
>>> > 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
>>
>>
>
>
> --
> Indradhanush Gupta
>
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20140615/95d427a0/attachment.htm>