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

Justin Karneges justin at affinix.com
Sun May 1 09:10:04 CEST 2016


I believe multipart messages are treated atomically, which means if
you're able to receive the first part then you're able to receive all
the remaining parts immediately. When QZmq was first written I was not
aware of the atomic handling, and so the code is probably more complex
than it needs to be.
 
On Sat, Apr 30, 2016, at 11:45 PM, Kalle Huttunen wrote:
> Hi, thanks for your answer. The README of your QZmq project rises up
> an interesting point: multipart messages. How do they work in relation
> to ZMQ_FD? When the FD signals read, have all message parts been
> received?
>
> --
> Kalle Huttunen
>
> la 30. huhtikuuta 2016 klo 23.16 Justin Karneges <justin at affinix.com>
> kirjoitti:
>> __
>> Expanding on your first point: the file descriptor only triggers read
>> notifications, and the notification means to query ZMQ_EVENTS. For
>> example, when a zmq socket becomes writable, the ZMQ_FD file
>> descriptor becomes readable, and you react to that by checking
>> ZMQ_EVENTS and discover the zmq socket can be written to.
>>
>> Also you may be interested in https://github.com/jkarneges/qzmq
>>
>> On Sat, Apr 30, 2016, at 12:32 PM, Kalle Huttunen 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/20160501/3a1fbcf7/attachment.htm>


More information about the zeromq-dev mailing list