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 <[email protected]> > 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 <[email protected] > <mailto:[email protected]>> 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 > > <[email protected] <mailto:[email protected]> <mailto:[email protected] > > <mailto:[email protected]>>> 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 <[email protected] > > <mailto:[email protected]> > > <mailto:[email protected] <mailto:[email protected]>>> 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 > > [email protected] <mailto:[email protected]> > > <mailto:[email protected] <mailto:[email protected]>> > > 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 > > [email protected] <mailto:[email protected]> > > https://lists.zeromq.org/mailman/listinfo/zeromq-dev > > <https://lists.zeromq.org/mailman/listinfo/zeromq-dev> > > > _______________________________________________ > zeromq-dev mailing list > [email protected] <mailto:[email protected]> > https://lists.zeromq.org/mailman/listinfo/zeromq-dev > <https://lists.zeromq.org/mailman/listinfo/zeromq-dev> > _______________________________________________ > zeromq-dev mailing list > [email protected] > https://lists.zeromq.org/mailman/listinfo/zeromq-dev
_______________________________________________ zeromq-dev mailing list [email protected] https://lists.zeromq.org/mailman/listinfo/zeromq-dev
