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

Justin Karneges justin at affinix.com
Mon May 2 10:15:33 CEST 2016


"update the state" is strange wording but it means you need to query
ZMQ_EVENTS.
 
And yes, you should assume that even a call to zmq_recv() might yield a
situation where there is more to read, but the fd doesn't become
readable. Basically, check ZMQ_EVENTS after every call to zmq_send or
zmq_recv, and whenever the fd becomes readable, regardless of which
events you are interested in.
 
On Mon, May 2, 2016, at 01:07 AM, Kalle Huttunen wrote:
> Okay, this one I missed because I was looking at an old version of the
> man page (http://api.zeromq.org/master:zmq-getsockopt takes you to
> 2.2.0 man page).
>
> Full quote from the 4.1.5 man page
> (http://api.zeromq.org/4-1:zmq-getsockopt):
>
> "The returned file descriptor is also used internally by the zmq_send
> and zmq_recv functions. As the descriptor is edge triggered,
> applications must update the state of ZMQ_EVENTS after each invocation
> of zmq_send or zmq_recv.To be more explicit: after calling zmq_send
> the socket may become readable (and vice versa) without triggering a
> read event on the file descriptor."
>
> This definitely sounds like a caveat I should handle. The quote raises
> some questions, though:
>
> - What exactly does it mean to "update the state of ZMQ_EVENTS"?
>
> - Do both zmq_send() and zmq_recv() reset all events in the FD? So if
>   I'm only interested on events about incoming messages (I check only
>   ZMQ_POLLIN from ZMQ_EVENTS), do I need to "update the state of
>   ZMQ_EVENTS" after both zmq_send() and zmq_recv(), or is it enough to
>   do it only after zmq_send()?
>
> --
> Kalle Huttunen
>
> ma 2. toukokuuta 2016 klo 4.16 KIU Shueng Chuan <nixchuan at gmail.com>
> kirjoitti:
>> From the man page for zmq_getsockopt:
>> "after calling zmq_send the socket may become readable (and vice
>> versa) without triggering a read event on the file descriptor."
>>
>> On 1 May 2016 3:33 am, "Kalle Huttunen" <khuttun at gmail.com> wrote:
>>> The ZeroMQ FAQ (http://zeromq.org/area:faq#toc5) states in the "Why
>>> can't I use standard I/O multiplexing functions such as select() or
>>> poll() on ZeroMQ sockets?" question:
>>>
>>> > Note that there's a way to retrieve a file descriptor from ZeroMQ
>>> > socket (ZMQ_FD socket option) that you can poll on from version
>>> > 2.1 onwards, however, there are some serious caveats when using
>>> > it. Check the documentation carefully before using this feature.
>>>
>>> I've prototyped integrating ZeroMQ socket receiving to Qt's and
>>> custom select() based event loops, and on the first glance
>>> everything seems to work.
>>>
>>> From the documentation I have identified two "caveats" that I handle
>>> in my code:
>>>
>>> 1. The ability to read from the returned file descriptor does not
>>>    necessarily indicate that messages are available to be read from
>>>    the socket
>>>
>>> This I have solved by checking ZMQ_EVENTS before reading from the
>>> socket.
>>>
>>> 2. Events are signaled in edge-triggered fashion
>>>
>>> This one I have solved by always receiving all the messages from the
>>> socket when the file descriptor signals.
>>>
>>> Are there some caveats that I'm missing?
>>>
>>> --
>>> Kalle Huttunen
>>>
>>> _______________________________________________
>>>  zeromq-dev mailing list
>>> zeromq-dev at lists.zeromq.org
>>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>> _______________________________________________
>>  zeromq-dev mailing list
>> zeromq-dev at lists.zeromq.org
>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> _________________________________________________
> 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/20160502/a5f5589b/attachment.htm>


More information about the zeromq-dev mailing list