In pseudocode, it might look like this: void check_events(zsock) { int revents = zsock.getsockopt(ZMQ_EVENTS); if (revents & ZMQ_POLLIN) { // "call_later" is some function that processes the call in the // next iteration of your event loop. call_later(on_readable); } }
// call this callback when the ZMQ_FD is readable void on_readable(zsock) { int revents = zsock.getsockopt(ZMQ_EVENTS); if (revents & ZMQ_POLLIN) { // call zmq_recv() repeatedly to receive all frames of a multipart message } check_events(zsock); } void do_send(zsock, msg) { zsock.send(msg); check_events(zsock); } On 2 May 2016 4:25 pm, "Kalle Huttunen" <khut...@gmail.com> wrote: So basically I will just write (I use the C++ bindings): mySocket.send(myMsg); mySocket.getsockopt(ZMQ_EVENTS); // Update the file descriptor state ? -- Kalle Huttunen ma 2. toukokuuta 2016 klo 11.15 Justin Karneges <jus...@affinix.com> kirjoitti: > > "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 _______________________________________________ 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