Re: [zeromq-dev] What are the “serious caveats” with ZMQ_FD?
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
Re: [zeromq-dev] What are the “serious caveats” with ZMQ_FD?
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
Re: [zeromq-dev] What are the “serious caveats” with ZMQ_FD?
Hi, thanks for your answer. The README of your QZmq project rises up an interesting point: multipart messages. How do they work in relation to ZMQ_FD? When the FD signals read, have all message parts been received? -- Kalle Huttunen la 30. huhtikuuta 2016 klo 23.16 Justin Karneges <jus...@affinix.com> kirjoitti: > Expanding on your first point: the file descriptor only triggers read > notifications, and the notification means to query ZMQ_EVENTS. For example, > when a zmq socket becomes writable, the ZMQ_FD file descriptor becomes > readable, and you react to that by checking ZMQ_EVENTS and discover the zmq > socket can be written to. > > Also you may be interested in https://github.com/jkarneges/qzmq > > On Sat, Apr 30, 2016, at 12:32 PM, Kalle Huttunen 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] What are the “serious caveats” with ZMQ_FD?
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
