[zeromq-dev] conventions in bindings
benjaminrk at gmail.com
Wed Feb 1 03:06:06 CET 2012
On Tue, Jan 31, 2012 at 17:23, Martin Sustrik <sustrik at 250bpm.com> wrote:
> * 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.
It sounds like the recommendation here is that czmq should stop doing what
it does, rather than other bindings following suit.
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the zeromq-dev