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

Pieter Hintjens ph at imatix.com
Thu Jul 8 08:54:40 CEST 2010

On Wed, Jul 7, 2010 at 6:39 PM, Martin Lucina <mato at kotelna.sk> wrote:

> Read up on the manuals for close() and setsockopt().
> Following the principle of least surprise and consistency with standard
> sockets, zmq_close() should not be a blocking call by default since
> close() isn't either.

The standard Linux man pages on close() and setsockopt() are not very
helpful. Do you have a URL to whatever manual page you're referring

However... following the principle of least surprise, send() would
block and apps would not lose data just because they forgot to
sleep(<insert random number here>).

We're already breaking the principle of least surprise in a major way,
obviously.  IMO it would be considerably less surprising to have
zmq_close() flush data, than to have data loss.

Further, close() _is_ a blocking call according to the man pages I'm
looking at (which is why it may return EINTR) though it's unclear
whether close() flushes data or not.

> As I mentioned in my original email you can alter the default behaviour
> of close() on sockets to be blocking, or even to do roughly what
> zmq_close() does now by manipulating the SO_LINGER socket option.

You're comparing TCP sockets with 0MQ sockets but it's not the right
comparison because send() is working so differently.  What we're doing
is caching data in application memory and deciding on semantics for
flushing that cache.  As you said yourself, the accurate comparison is
between 0MQ sockets and a file system.

So, does fclose() flush data?  Yes, it does.  Does it do a fsync to
ensure the data is actually written to disk?  No, that's the OS's
problem.  It's precisely the same here.

Still, it's moot IMO, the only difference between flushing in
zmq_close() and zmq_term() will be for applications that create and
destroy many sockets, which is probably a buggy pattern.


More information about the zeromq-dev mailing list