[zeromq-dev] zmq_close() semantics and handling outstanding messages

Brian Granger ellisonbg at gmail.com
Tue Jul 6 21:21:19 CEST 2010

Oh, I forgot the mention another point about this.

I have started to put time.sleep(?) calls at the end of my zmq
applications because of this.  But, this has a huge problem that is
almost impossible to fix with the current API.  The amount of time I
need to sleep before calling zmq_term is unpredictable and depends on
things like:

* This number of outstanding messages.
* The size of the outstanding messages.

There isn't really any way of knowing these things in general, so if
my application will have lots of large messages, I have to put in
*really* long sleeps before shutting down.  I would much rather have
zmq_term block for exactly the right amount of time.



On Tue, Jul 6, 2010 at 10:24 AM, Martin Lucina <mato at kotelna.sk> wrote:
> Hi all,
> while implementing a 0MQ architecture which needs to dynamically create and
> destroy sockets during operation I ran into the current behaviour of
> zmq_close() being semantically different from the standard close() system
> call.
> Consider a scenario where we wish to send a bunch of messages, then close
> the socket:
>  zmq_send (s, ...)
>  zmq_send (s, ...)
>  zmq_send (s, ...)
>  zmq_close (s)
> The current behaviour is that zmq_close() will discard any messages which
> have been queued ("sent") with zmq_send() but have not yet been pushed out
> to the network. Contrast this with the behaviour of the close() system call
> on a standard socket where the call means "please make this socket go away,
> but finish sending any outstanding data on it asynchronously if you
> can"[1].
> In my opinion the proper solution is to use the same semantics as the
> close() system call, in other words, zmq_close() shall invalidate the
> socket from the caller's point of view so no further operations may be
> performed on it, but 0MQ shall send any outstanding messages in the
> background *as long as a endpoint for those messages still exists* before
> destroying the socket "for real".
> This would mean a second change to the API which would make zmq_term() a
> blocking call, since it would need to wait until all outstanding messages
> are sent. The analogous functionality for the close() system call is
> handled by the OS kernel -- obviously if the OS shuts down then data will
> be lost.
> The downside is that zmq_term() could freeze for an arbitrary amount of
> time if the remote end is "stuck". For applications where this is
> undesirable it would mean adding a "KILL" flag or separate zmq_term_kill()
> function which means "we don't care, really go away now".
> Please let me know your opinions on this change; ultimately I think it's
> the right way to go especially if OS integration of 0MQ sockets is (a long
> way) down the road.
> -mato
> [1] This behaviour can be changed using the SO_LINGER option, we'd probably
> want to implement a similar option for 0MQ sockets.
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Brian E. Granger, Ph.D.
Assistant Professor of Physics
Cal Poly State University, San Luis Obispo
bgranger at calpoly.edu
ellisonbg at gmail.com

More information about the zeromq-dev mailing list