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>
Server:
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)) {
zmq_msg_close(&msg);
throw_send_error(errno);
}
zmq_msg_close(&msg);
zmq_msg_init(&recv_msg);
if (zmq_recv(socket_, &recv_msg, 0)) { // <<<< Hangs here
zmq_msg_close(&recv_msg);
throw_recv_error(errno);
}
======= Receiving code (in another process) :
zmq_msg_t msg;
zmq_msg_init(&msg);
{ // unlock worker
ScopedUnlock unlock(worker_);
if (zmq_recv(socket_, &msg, 0)) { // <<<<< Hangs here
zmq_msg_close(&msg);
throw_recv_error(errno);
}
}
Any idea on what could cause these dropped messages ?
Gaspard
On Thu, Jan 6, 2011 at 2:08 PM, Martin Sustrik <[email protected]> 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
>
_______________________________________________
zeromq-dev mailing list
[email protected]
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
