[zeromq-dev] libev and ZMQ
Bill Torpey
wallstprog at gmail.com
Sat Apr 10 17:23:18 CEST 2021
Hi Arun:
This thread may be helpful: https://lists.zeromq.org/mailman/private/zeromq-dev/2014-July/026350.html <https://lists.zeromq.org/mailman/private/zeromq-dev/2014-July/026464.html>
It appears from the thread that it’s not a good idea to rely on the events being level-triggered, and that which you get depends on which underlying event mechanism is being used by libzmq.
Hope this helps.
Bill
> On Apr 10, 2021, at 2:48 AM, Arun Athrey Chandrasekaran <achandr8 at ncsu.edu> wrote:
>
> 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 <mailto: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> <mailto: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>
> > <mailto: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>
> > <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> <mailto: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>
> > <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 <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 <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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20210410/a183ca69/attachment.htm>
More information about the zeromq-dev
mailing list