[zeromq-dev] zmq_ctx_term vs zmq_ctx_destroy vs zmq_ctx_shutdown

Pieter Hintjens ph at imatix.com
Sun Jun 15 15:03:44 CEST 2014

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

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.


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

More information about the zeromq-dev mailing list