[zeromq-dev] Why doesn't 0mq save fd by merging sockets connecting to the same address?

[Martin Sustrik]

On 10/17/2011 09:03 AM, Yichao Zhang wrote:
> Won't some 0mq socket types benefit from multiplexing over TCP, say the
> receivers connecting to a load balancing sender? Say you have 100 PULL
> sockets all connecting to the same PUSH socket, any PULLer can wake up
> and read the first packet out. The problem you describes doesn't affect
> this case.

In this case there's only one PUSH socket (although handling 100 
underlying TCP sockets). The overhead is 1 fd for internal use of the 
socket.

If this additional 1 fd per 0MQ socket is the problem you are trying to 
solve, it have used to be that way in old versions of 0MQ. The fd was 
shared between multiple 0MQ sockets. However, that created a tight 
binding between a 0MQ socket and the application thread. Two sockets 
using the same fd had to belong to the same thread, otherwise the 
threads could try to write to the fd in parallel, resulting in race 
conditions.

While this tight binding doesn't look too restrictive, it creates a 
problem when socket is migrated between two threads. Unfortunately, 
that's exactly what's happening in many language bindings. For example, 
imagine JVM passing a socket to garbage collection thread to be deallocated.

Martin