[zeromq-dev] zmq2 vs zmq1 features questions

Pavel Gushcha pavimus at gmail.com
Tue Dec 22 12:43:09 CET 2009

2009/12/22 Martin Sustrik <sustrik at 250bpm.com>

> 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.

Super. nothing is simple than that :-)

> 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.

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.

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

>  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? 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)

>  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.

Thanks, it seems, this will solve my tasks

> 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.
> Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20091222/4f79ed30/attachment.htm>

More information about the zeromq-dev mailing list