[zeromq-dev] libev and ZMQ
Arun Athrey Chandrasekaran
achandr8 at ncsu.edu
Sat Apr 10 08:48:54 CEST 2021
Hi all,
I have a different query now. Can libev miss events while the
callback is being executed? I have two ev_io watchers on two different
sockets but the callback function is the same. When there is activity on
either of the sockets, the callback gets called. The activity I watch for
is EV_READ (i.e, whether there is anything to be read from the socket). At
the end of the callback routine, I check the sockets again to see if there
is any activity (just to be sure) and I sometimes notice there does exist
an event (one of the two sockets is readable). If I don't service this, the
event gets missed. That is, I don't get a callback again for the event
noticed at the end of the callback routine. Is this expected?
Thanks,
*Arun*
On Mon, Mar 8, 2021 at 4:22 AM Arnaud Loonstra <arnaud at sphaero.org> wrote:
> Hi Arun,
>
> I'm not sure what to spot. I'm using czmq mostly and hardly ever libzmq
> directly. But I also just see libzmq code and not libev, or did I miss
> something? What you are referring to is when you are doing
> filedescriptor polling yourself without libzmq's poll methods.
>
> Also I don't have any experience with Go. Can't advice you there.
>
> Rg,
>
> Arnaud
>
> On 06-03-2021 22:49, Arun Athrey Chandrasekaran wrote:
> > Arnaud,
> > Following up on my previous email, please see samples of my
> > client and server codes attached showing how I use the ZMQ APIs. The
> > endpoints are TCP-based. The client sends a message over the REQ socket
> > and expects a response from the server over the SUB socket. The server
> > routine gets called on socket activity and after a ZMQ poll, it responds
> > according to the received message over the PUB socket. After the server
> > is done with recv/send, it does a ZMQ poll (which is expected to do
> > this: "..../applications must retrieve the actual event state with a
> > subsequent retrieval of the 'ZMQ_EVENTS' option."/ )
> >
> > Thanks,
> > *Arun*
> >
> > On Thu, Feb 25, 2021 at 12:54 PM Arun Athrey Chandrasekaran
> > <achandr8 at ncsu.edu <mailto:achandr8 at ncsu.edu>> wrote:
> >
> > Arnaud,
> > As you correctly point out,
> >
> > /"The ability to read from the returned file descriptor does not
> > necessarily indicate that messages are available to be read from, or
> > can be written to, the underlying socket; applications must retrieve
> > the actual
> > event state with a subsequent retrieval of the 'ZMQ_EVENTS' option."
> > /
> >
> > This may be causing the problem. Even after the client sends a
> > message and the server responds, I get one or two more calls from
> > libev. In the callback though, I do a ZMQ poll which comes back with
> > no events. My client code is in golang and my server code is in C++.
> > After receive and send I do a ZMQ poll in the server to take care of
> > this:
> >
> > "applications must retrieve the actual event state with a subsequent
> > retrieval of the 'ZMQ_EVENTS' option"
> >
> > I don't know if the client should do something after send/receive
> > and FWIW, I have tried a few different APIs in golang to achieve
> > the above but to no avail.
> >
> > Thanks,
> > *Arun*
> >
> >
> >
> > On Thu, Feb 25, 2021 at 12:27 PM Arnaud Loonstra <arnaud at sphaero.org
> > <mailto:arnaud at sphaero.org>> wrote:
> >
> > On 25-02-2021 19:35, Arun Athrey Chandrasekaran wrote:
> > > Hi all,
> > > Are there any gotchas w.r.t using libev with ZMQ? I
> > want to
> > > use ZMQ to receive and send messages from/to another process
> and
> > > instead of a ZMQ server in an infinite loop listening for
> > incoming
> > > requests, I want to use libev to look for socket activity.
> > What I have
> > > found out so far is that even when there is no real socket
> > activity, I
> > > still get "ghost" callbacks from libev. I tried updating the
> > ZMQ_EVENTS
> > > on both client and server sides after ZMQ recv and send but
> > that did not
> > > help.
> > >
> > > Thanks,
> > > *Arun*
> > >
> >
> > Hi Arun,
> >
> > If you have some concept code it would really help. You can use
> > zeromq
> > in any event system which is able to poll on file descriptors.
> > There are
> > some caveats you have to be aware of. I'm not sure how this is
> > done with
> > the newer threadsafe sockets though.
> >
> > From
> >
> https://github.com/zeromq/libzmq/blob/2bf998f7e0aa19e89918627d386d526e4f2e25dd/doc/zmq_getsockopt.txt
> > <
> https://github.com/zeromq/libzmq/blob/2bf998f7e0aa19e89918627d386d526e4f2e25dd/doc/zmq_getsockopt.txt
> >"
> >
> > The 'ZMQ_FD' option shall retrieve the file descriptor
> > associated with the
> > specified 'socket'. The returned file descriptor can be used to
> > integrate the
> > socket into an existing event loop; the 0MQ library shall signal
> > any pending
> > events on the socket in an _edge-triggered_ fashion by making
> > the file
> > descriptor become ready for reading.
> >
> > NOTE: The ability to read from the returned file descriptor does
> not
> > necessarily indicate that messages are available to be read
> > from, or can be
> > written to, the underlying socket; applications must retrieve
> > the actual
> > event
> > state with a subsequent retrieval of the 'ZMQ_EVENTS' option.
> >
> > NOTE: 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.
> >
> > CAUTION: The returned file descriptor is intended for use with a
> > 'poll' or
> > similar system call only. Applications must never attempt to
> > read or
> > write data
> > to it directly, neither should they try to close it.
> >
> >
> > Rg,
> >
> > Arnaud
> > _______________________________________________
> > zeromq-dev mailing list
> > zeromq-dev at lists.zeromq.org <mailto:zeromq-dev at lists.zeromq.org>
> > https://lists.zeromq.org/mailman/listinfo/zeromq-dev
> > <https://lists.zeromq.org/mailman/listinfo/zeromq-dev>
> >
> >
> > _______________________________________________
> > zeromq-dev mailing list
> > zeromq-dev at lists.zeromq.org
> > https://lists.zeromq.org/mailman/listinfo/zeromq-dev
> >
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> https://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20210409/b2259c7a/attachment.htm>
More information about the zeromq-dev
mailing list