[zeromq-dev] zmq2 vs zmq1 features questions

Martin Sustrik sustrik at 250bpm.com
Tue Dec 22 11:59:59 CET 2009

Pavel Gushcha wrote:
> 1. My application is multithreaded. About what i must care? I only must 
> specify required app_threads in zmq_init and protect operations with 
> context by mutex?

It's simpler than that. There are only 2 operations with context, namely 
zmq_init and zmq_term. Presumably, you'll invoke these two from the main 
thread. No mutex is needed.

All remaining operations are related to sockets. The rule is that each 
socket can be used from only a single thread. So you have to create, use 
and destroy the socket from the _same_ thread. This assures no need for 
thread synchronisation (mutexes) on application level.

> 2. Is there something like back protocol watermarks in zmq1?

This is a features that haven't been ported to 2.0 yet :(

> 3. In zmq1 we can receive messages in one receive() call from many 
> queues, and receive() returns queue identifier. In zmq2 we have two 
> possibilities:
> a) create one socket and connect it to all message sources. Now we may 
> use recv() for waiting for any message from any source. But after 
> receiving we can't determine from which source message is received.
> b) create many sockets and connect them to message sources. Now each 
> socket is connected to one message source, and there is no problem with 
> determining message source. But we can't make one blocking recv() for 
> waiting any message from any source.
> In other words, i need use one blocking recv() for waiting message from 
> any source and i must determine message source. Moreover, in some cases 
> i need disabling/enabling receiving messages from some sources (like 
> consume() in zmq1)
> If now there is no such functionaly how is the better way to build it? 
> may be sockets bind() and connect() should return something like 
> identifier, and recv() will return this identifier?

You can open multiple sockets and wait for incoming messages using zmq_poll.

Another option (more sensible IMO) is to simply to place the source ID 
to the message on the application level.

The third possibility would be to modify 0MQ so that user would be able 
to retrieve the identity of the peer witch sent the last received 
message. Someting like this.

s.recv (&msg);
char buff [255];
int nbyes = s.getsockopt (s, ZMQ_PEER_IDENTITY, buf, sizeof (buf));

However, I am not sure about the latter option as it would have 
performance impact associated with passing the identity between I/O and 
application threads.

> 4. Is something like

Oops. It seems that your email is truncated for some reason.


More information about the zeromq-dev mailing list