[zeromq-dev] Need to PUB / REQ from multiple threads

Gaspard Bucher gaspard at teti.ch
Sun Jan 9 22:32:01 CET 2011

Hi Martin,

Thanks for your help. I first thought there was something like the OpenGL
thread context preventing sockets to be used by different threads. I am glad
to know that this is not the case. I went through my code and discovered
some non-reentrant methods that were not properly protected. Once this was
fixed, a lot of issues went away but I still have one big problem:

I loose packets... ?!

My setup is very simple: when the user moves a slider this triggers a
(zmq.REQ) send and recv to the server. I am logging send and receive
operations on the client and server sides and sometimes the reply is never
received and the GUI hangs (the remote server is just echoing messages):

Client GUI:
Mimas ---> 0,59333333333333
Mimas <--- 0,59333333333333
Mimas ---> 0,6
Mimas <--- 0,6
Mimas ---> 0,60666666666667
<thread waiting in recvfrom>

Saturn <--- 0.59333333333333
Saturn ---> 0.59333333333333
Saturn <--- 0.6
Saturn ---> 0.6
<thread waiting in recvfrom>

The "send" operation seems to be handled fine: I am checking all return
values and nothing is thrown. Here is the offending code:

      if (zmq_send(socket_, &msg, 0)) {



      if (zmq_recv(socket_, &recv_msg, 0)) { // <<<< Hangs here

======= Receiving code (in another process) :

    zmq_msg_t msg;

    { // unlock worker
      ScopedUnlock unlock(worker_);

      if (zmq_recv(socket_, &msg, 0)) { // <<<<< Hangs here

Any idea on what could cause these dropped messages ?


On Thu, Jan 6, 2011 at 2:08 PM, Martin Sustrik <sustrik at 250bpm.com> wrote:

> Hi Gaspard,
>  The mutex is not process-wide but linked to a Lua context (and a zmq
>> context).
> What I meant was: If you don't care that all your threads would block each
> another on the mutex, you can use it.
>  Reading through the code and manual or reference I could not
>> find how this migration between threads is supposed to be done. The only
>> reference on socket migration I found was this:
>>     //  At this  point we migrate the log socket to the current thread.
>>     //  We rely on mutex for executing the memory barrier.
>>     log_sync.lock ();
>>     if (log_socket)
>>         log_socket->send (msg_, 0);
>>     log_sync.unlock ();
>> Appart from locking, I do not see any "plug" or "unplug" method called.
>> How is this supposed to be done ?
> You don't need any special functions. The lock should do (it executes the
> memory barriers needed).
> Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20110109/0f126039/attachment.htm>

More information about the zeromq-dev mailing list