[zeromq-dev] conventions in bindings

Martin Sustrik sustrik at 250bpm.com
Wed Feb 1 02:23:04 CET 2012


> * SUB sockets default to SUBSCRIBE("") instead of None

This becomes a problem with 3.0 and subscription forwarding. The problem 
occurs when you don't want to subscribe to all messages. You open a 
socket and unsubscribe from "". However, between the two operations you 
can be overloaded by huge amount of irrelevant messages from the publisher.

> * LINGER is a property of the Context, and sets a default value for its
> sockets, which is 0 by default, instead of -1

The problem with default LINGER equal to 0 is that following program 
doesn't send any message (the socket is destroyed before connection is 

    s = zmq_socket (ctx, ZMQ_PUSH);
    zmq_connect ("tcp://server0001:5555");
    zmq_send (s, "ABC", 3, 0);
    zmq_close (s);

That's an extremely unintuitive behaviour.

If default linger time of infinity is causing troubles I would rather 
suggest going for something like 1 second.

> czmq has `zctx_destroy()`, which sets LINGER, closes sockets, and
> ultimately terminates the context.  PyZMQ has *similar* behavior in
> Context.destroy(), where setting LINGER before closing is an optional
> argument, and does not happen by default.

First, let me explain why libzmq doesn't do this kind of thing.

As can be seen from czmq this functionality can only be implemented when 
the library either assumes that sockets are never migrated between 
threads or that migration is announced to the library in an explicit 
manner (calling a function or similar).

This is not case for libzmq. For example, when using Java binding, Java 
virtual machine can choose to migrate the socket object to the gc thread 
without notifying libzmq about the fact.

Second, the lesson for individual bindings: You can implement this 
functionality only if the binding has full control of the threading, 
i.e. when you can keep the list of sockets owned by the particular 
thread and the language runtime cannot move the sockets to different 
threads thus rendering your per-thread socket lists invalid.


More information about the zeromq-dev mailing list