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

[Martin Lucina]

On 7/7/2010, "Pieter Hintjens" <ph at imatix.com> wrote:

>On Wed, Jul 7, 2010 at 9:35 AM, Pieter Hintjens <ph at imatix.com> wrote:
>
>> Does anyone see problems with this approach?
>
>Sorry, for some reason Mato's original email slipped past me...
>
>Mato, +1 on making zmq_term a blocking call.  

> I'd probably make
>zmq_close a blocking call as well, and offer a socket option to
>disable this per socket.

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.

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.

Now, I've never actually seen any code that uses SO_LINGER but if enough
people want that then it could be implemented for 0MQ sockets.

>Do we have use cases for applications that need to kill 0MQ right
>away?  I'd suggest that this can be done e.g. by destroying the
>context and not calling zmq_term().

zmq_term() is the only way to destroy a context at the moment.

-mato