[zeromq-dev] What are the “serious caveats” with ZMQ_FD?

Huttunen, Kalle (GE Healthcare) Kalle.Huttunen at ge.com
Tue May 24 07:22:20 CEST 2016


> 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-bounces at 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.Huttunen at ge.com<mailto:Kalle.Huttunen at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20160524/f5458b43/attachment.htm>


More information about the zeromq-dev mailing list