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
<achan...@ncsu.edu <mailto:achan...@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 <arn...@sphaero.org
<mailto: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
<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 <mailto:zeromq-dev@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@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
