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
actualevent 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 <arn...@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
> "
>
> 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@lists.zeromq.org
> https://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
_______________________________________________
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
https://lists.zeromq.org/mailman/listinfo/zeromq-dev
