[zeromq-dev] conventions in bindings

[MinRK]

On Tue, Jan 31, 2012 at 17:23, Martin Sustrik <sustrik at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20120131/3a08c7ef/attachment.htm>