> 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