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

Doron Somech somdoron at gmail.com
Tue May 24 08:48:49 CEST 2016


Only if you are using thread safe sockets. You can save a call by with just
calling with ZMQ_NOBLOCK (no need for ZMQ_EVENTS). Then you don't need to
worry about race condition.
On May 24, 2016 08:22, "Huttunen, Kalle (GE Healthcare)" <
Kalle.Huttunen at ge.com> wrote:

> > 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> 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 at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20160524/691e13a6/attachment.htm>


More information about the zeromq-dev mailing list