[zeromq-dev] zmq_term() blocks in 2.1

David Kantowitz dkantowitz at gmail.com
Tue Jan 11 02:05:14 CET 2011

> Date: Mon, 10 Jan 2011 18:36:19 -0600
> From: Chuck Remes <cremes.devlist at mac.com>
> Subject: Re: [zeromq-dev] zmq_term() blocks in 2.1
> To: ZeroMQ development list <zeromq-dev at lists.zeromq.org>
> Message-ID: <5AAAD829-F8ED-447D-9D88-568C8198CB6C at mac.com>
> Content-Type: text/plain; CHARSET=US-ASCII
> On Jan 10, 2011, at 6:26 PM, David Kantowitz wrote:
> > Hello,
> >
> > In v2.1 zmq_term() will block if there are any open sockets -- in
> previous versions of ZMQ zmq_term() was non-blocking.
> >
> > For my application this causes problems, so I've changed my copy of
> ctx::terminate() to be non-blocking.  I issue all the stop() calls and
> return EAGAIN if there are sockets other then the logging socket open.
> >
> > However I didn't see an obvious way to extend the ZMQ API (ex, context
> level option) to support both behaviors so there isn't much point in
> submitting my change ... it would be wrong for the people who want a
> blocking zmq_term().
> >
> > I do think it is worth having non-blocking support.  Since an API change
> or addition seems necessary, perhaps it would be good to add this before 2.1
> is finalized.
> >
> > How are issues like best captured?  Should I submit a bug report
> somewhere?
> This topic has been discussed numerous times on the list so I suggest you
> search through some of the old threads to become familiar with the main
> developer's responses.
> While I think Martin is considering some kind of change to allow zmq_term()
> to return EAGAIN, such a change would break the existing API contract for
> 2.1 which *is* finalized. Any change to this behavior would be part of a 2.2
> (or later) branch.
> cr


Thanks for pointing me back to the older discussions.  I read through some
of emails and I think what I want is somewhat simpler then the issues
discussed.  I don't care if messages are fully flushed at the time
zmq_term() returns, I just don't want zmq_term() to hang my main thread.

Anyway, this is the benefit of opensource, I can simply change zmq  to
behave the way that makes sense to me.

Thanks again,
David K.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20110110/0e66e91a/attachment.htm>

More information about the zeromq-dev mailing list