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

Pieter Hintjens ph at imatix.com
Wed Jul 7 09:35:33 CEST 2010

On Wed, Jul 7, 2010 at 9:23 AM, Martin Lucina <mato at kotelna.sk> wrote:

> The confusion with the API changes in the 2.0.7 release and the resulting
> stable release discussion came from the fact that Martin Sustrik and
> myself had defined the 2.0.x series as "Beta" until such point that it
> was declared "Stable". It's now obvious that the community has
> declared 2.0.x "Stable", which from my point of view basically means
> 2.0.x will be frozen and changes like this would go into a 2.1.x release.

It was obviously time to declare 0MQ/2.0.x as Stable, given the amount
of work resting on it, both as apps and as language bindings.  I don't
see that we need to start designing 0MQ/3.x.  We're not yet finished
making 2.x work properly, and the current semantics for close/term
seem like unfinished work.

Your analogy with writing to a file is accurate; we do not need
guarantees that the data has been written but simply assurance that
it's been handed off to the operating system.

It seems obvious that closing a socket should clear out all messages
waiting to be sent.  Terminating 0MQ would do this for all open
sockets.  If people need the current semantics (which seem pointless
but you never know) they could be requested on a per-socket basis
using setsockopt().

Does anyone see problems with this approach?


More information about the zeromq-dev mailing list