> after your call to zmq_recv(), but before your call to select() / poll()
Are you talking about the way to receive messages when the ZMQ_FD signals?
Basically I currently have the following code called when the ZMQ_FD becomes
readable (in pseudocode):
while ZMQ_EVENTS has ZMQ_POLLIN bit set
{
receive message from socket;
process message;
}
Is there a potential race condition here?
Thanks,
--
Kalle Huttunen
From: zeromq-dev [mailto:zeromq-dev-boun...@lists.zeromq.org] On Behalf Of Dave
Lambley
Sent: 23. toukokuuta 2016 19:08
To: ZeroMQ development list
Subject: EXT: Re: [zeromq-dev] What are the “serious caveats” with ZMQ_FD?
On 23 May 2016 at 10:23, Huttunen, Kalle (GE Healthcare)
<kalle.huttu...@ge.com<mailto:kalle.huttu...@ge.com>> wrote:
It seems that sending on the socket makes the ZMQ_FD readable. That in turn
triggers the calling of the code where I check ZMQ_EVENTS and receive
everything from the socket. This way I end up checking ZMQ_EVENTS after each
send.
Is the ZMQ_FD becoming readable when sending on the socket something that can
be relied on?
I believe you have a race condition. If a message arrives after your call to
zmq_recv(), but before your call to select() / poll(), it will block despite
there being a message ready.
If you can tolerate messages being delayed, there is an simple workaround in
which you call zmq_recv() periodically. We have code doing this by specifying a
timeout in the select() call.
Dave
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
