Re: [zeromq-dev] What are the “serious caveats” with ZMQ_FD?
Only if you are using thread safe sockets. You can save a call by with just calling with ZMQ_NOBLOCK (no need for ZMQ_EVENTS). Then you don't need to worry about race condition. On May 24, 2016 08:22, "Huttunen, Kalle (GE Healthcare)" < kalle.huttu...@ge.com> wrote: > > after your call to zmq_recv(), but before your call to select() / poll() > > > > Are you talking about the way to receive messages when the ZMQ_FD signals? > Basically I currently have the following code called when the ZMQ_FD > becomes readable (in pseudocode): > > > > while ZMQ_EVENTS has ZMQ_POLLIN bit set > > { > > receive message from socket; > > process message; > > } > > > > Is there a potential race condition here? > > > > Thanks, > > -- > > Kalle Huttunen > > > > *From:* zeromq-dev [mailto:zeromq-dev-boun...@lists.zeromq.org] *On > Behalf Of *Dave Lambley > *Sent:* 23. toukokuuta 2016 19:08 > *To:* ZeroMQ development list > *Subject:* EXT: Re: [zeromq-dev] What are the “serious caveats” with > ZMQ_FD? > > > > On 23 May 2016 at 10:23, Huttunen, Kalle (GE Healthcare) < > kalle.huttu...@ge.com> wrote: > > It seems that sending on the socket makes the ZMQ_FD readable. That in > turn triggers the calling of the code where I check ZMQ_EVENTS and receive > everything from the socket. This way I end up checking ZMQ_EVENTS after > each send. > > Is the ZMQ_FD becoming readable when sending on the socket something that > can be relied on? > > > > I believe you have a race condition. If a message arrives after your call > to zmq_recv(), but before your call to select() / poll(), it will block > despite there being a message ready. > > If you can tolerate messages being delayed, there is an simple workaround > in which you call zmq_recv() periodically. We have code doing this by > specifying a timeout in the select() call. > > Dave > > > > ___ > 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?
> after your call to zmq_recv(), but before your call to select() / poll() Are you talking about the way to receive messages when the ZMQ_FD signals? Basically I currently have the following code called when the ZMQ_FD becomes readable (in pseudocode): while ZMQ_EVENTS has ZMQ_POLLIN bit set { receive message from socket; process message; } Is there a potential race condition here? Thanks, -- Kalle Huttunen From: zeromq-dev [mailto:zeromq-dev-boun...@lists.zeromq.org] On Behalf Of Dave Lambley Sent: 23. toukokuuta 2016 19:08 To: ZeroMQ development list Subject: EXT: Re: [zeromq-dev] What are the “serious caveats” with ZMQ_FD? On 23 May 2016 at 10:23, Huttunen, Kalle (GE Healthcare) mailto:kalle.huttu...@ge.com>> wrote: It seems that sending on the socket makes the ZMQ_FD readable. That in turn triggers the calling of the code where I check ZMQ_EVENTS and receive everything from the socket. This way I end up checking ZMQ_EVENTS after each send. Is the ZMQ_FD becoming readable when sending on the socket something that can be relied on? I believe you have a race condition. If a message arrives after your call to zmq_recv(), but before your call to select() / poll(), it will block despite there being a message ready. If you can tolerate messages being delayed, there is an simple workaround in which you call zmq_recv() periodically. We have code doing this by specifying a timeout in the select() call. Dave ___ 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?
On 23 May 2016 at 10:23, Huttunen, Kalle (GE Healthcare) < kalle.huttu...@ge.com> wrote: > It seems that sending on the socket makes the ZMQ_FD readable. That in > turn triggers the calling of the code where I check ZMQ_EVENTS and receive > everything from the socket. This way I end up checking ZMQ_EVENTS after > each send. > > Is the ZMQ_FD becoming readable when sending on the socket something that > can be relied on? > I believe you have a race condition. If a message arrives after your call to zmq_recv(), but before your call to select() / poll(), it will block despite there being a message ready. If you can tolerate messages being delayed, there is an simple workaround in which you call zmq_recv() periodically. We have code doing this by specifying a timeout in the select() call. Dave ___ 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?
I would not rely on this. Query ZMQ_EVENTS after every send no matter what. On Mon, May 23, 2016, at 02:23 AM, Huttunen, Kalle (GE Healthcare) wrote: > It seems that sending on the socket makes the ZMQ_FD readable. That in > turn triggers the calling of the code where I check ZMQ_EVENTS and > receive everything from the socket. This way I end up checking ZMQ_EVENTS > after each send. > > Is the ZMQ_FD becoming readable when sending on the socket something that > can be relied on? > > -- > 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
Re: [zeromq-dev] What are the “serious caveats” with ZMQ_FD?
It seems that sending on the socket makes the ZMQ_FD readable. That in turn triggers the calling of the code where I check ZMQ_EVENTS and receive everything from the socket. This way I end up checking ZMQ_EVENTS after each send. Is the ZMQ_FD becoming readable when sending on the socket something that can be relied on? -- Kalle Huttunen ___ 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?
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" 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 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 > 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" 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
Re: [zeromq-dev] What are the “serious caveats” with ZMQ_FD?
On Saturday 30 Apr 2016 19:32:56 Kalle Huttunen wrote: > 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 [...] > > Are there some caveats that I'm missing? One little thing that tripped me up. If you're using PGM, sending though a PUB and listening for incoming traffic on a SUB, you might think you only need to monitor the FD on the SUB socket. In fact any NAK from a client gets sent to the PUB socket, so you need to monitor it's FD for incoming traffic too. Using either to trigger calling zmq_poll() on the SUB socket will get NAK responses sent properly. If you don't monitor the PUB socket FD, only call zmq_recv() or zmq_poll() on an event, and don't have any traffic to zmq_send(), PGM NAKs won't get processed. -- Jim Hague - jim.ha...@acm.org Never trust a computer you can't lift. ___ 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?
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 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 > 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" 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?
"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 > 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" 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
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 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" 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?
>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" 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
Re: [zeromq-dev] What are the “serious caveats” with ZMQ_FD?
I believe multipart messages are treated atomically, which means if you're able to receive the first part then you're able to receive all the remaining parts immediately. When QZmq was first written I was not aware of the atomic handling, and so the code is probably more complex than it needs to be. On Sat, Apr 30, 2016, at 11:45 PM, Kalle Huttunen wrote: > 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 > 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 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 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
Re: [zeromq-dev] What are the “serious caveats” with ZMQ_FD?
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] 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