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

KIU Shueng Chuan nixchuan at gmail.com
Tue May 3 04:09:15 CEST 2016


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" <khuttun at 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 <justin at 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 <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
>
> _______________________________________________
> 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



More information about the zeromq-dev mailing list