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 <[email protected]> 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" <[email protected]> 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 >> [email protected] >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev >> > _______________________________________________ > zeromq-dev mailing list > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
