[zeromq-dev] zmq2 vs zmq1 features questions

Martin Sustrik sustrik at 250bpm.com
Wed Dec 23 13:34:25 CET 2009

Hi Pavel,

> Can i create socket in one thread and pass it to second thread for use 
> (logic guarantees, that there is no simulateniously access to socket 
> from many threads)? My main thread will create two threads, first will 
> use bind() and second will use connect(). In zmq1 for objects not listed 
> in zmq_server.conf we need first create global queue/exchange and then 
> connect to it, otherwise we will get error. So for zmq1 i create global 
> queue/exchange in main thread, then create other threads and pass global 
> queue pointer to required thread for using.

No, socket cannot be passed between the threads even if you guarantee 
that it won't be called from two threads simultaneously. What you should 
do instead is to pass the context between threads and use it in each 
thread to create the sockets needed in that thread.

> Or in zmq2 order of bind/connect calls is not so critical for tcp / 
> inproc communication?

There's reconnect mechanism meaning that TCP connect socket will try to 
reconnect to non-existent bind socket till it is created and connect 
succeeds. However, it doesn't work that way for inproc sockets.

>         2. Is there something like back protocol watermarks in zmq1?
>     This is a features that haven't been ported to 2.0 yet :(
> I have app1 that produces messages and app2 that consumes messages. What 
> will be happened if app2 will slowdown?
> 1) if sockets are pub/sub some messages will be lost?
> 2) if sockers are downstream/upstream no messages will be lost and app1 
> will be blocked from time to time?

No, no messages will be dropped. The buffer will simply grow without a 

> Number of mesages buffered to send in 
> app1 and for recv in app2 is limited ONLY by watermarks specified by 
> sockopts or there is additional buffers like backprotocol in zmq1? (My 
> messages have big size and i wrote set_watermarks() function for zmq1 to 
> change default bp_hwm and bp_lwm to plausible values)

Yes. I recall. In 0MQ/2.0 limits are not implemented, however, the plan 
is that HWM/LWM will be the only limits, no additional buffers are to be 


More information about the zeromq-dev mailing list