On Tue, Jan 31, 2012 at 17:23, Martin Sustrik <sust...@250bpm.com> wrote:
> Hi,
>
>
> * 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
> established):
>
> 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.
-MinRK
>
>
> 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.
>
> Martin
>
_______________________________________________
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
