"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 <nixch...@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" <khut...@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@lists.zeromq.org >>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev >> _______________________________________________ >> zeromq-dev mailing list >> zeromq-dev@lists.zeromq.org >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev > _________________________________________________ > zeromq-dev mailing list > zeromq-dev@lists.zeromq.org > http://lists.zeromq.org/mailman/listinfo/zeromq-dev
_______________________________________________ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
