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
[zeromq-dev] Malamute Users - Service Requests API
Hi, I am new to Malamute and wanted to exchange words with some other user of the Service Requests API in Malamute. Malamute being a message broker, I expected to find some sort of timeout and/or retry logic for in-flight service requests, but from the API I don't think those exist. I wonder how people use the Service Request API to accomplish that. Thanks, Osiris ___ 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
