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

[Kalle Huttunen]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20160502/c98aafcb/attachment.htm>