Re: [zeromq-dev] libev and ZMQ

[Bill Torpey]

Hi Arun:

This thread may be helpful: 
https://lists.zeromq.org/mailman/private/zeromq-dev/2014-July/026350.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  
> 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  > 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 
> > 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  > 
> > >> 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
> >  

Re: [zeromq-dev] libev and ZMQ

[Arun Athrey Chandrasekaran]

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  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
> > 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  > > 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
> > 

Re: [zeromq-dev] libev and ZMQ

[Arnaud Loonstra]

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 
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 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

"

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 

Re: [zeromq-dev] libev and ZMQ

[Arun Athrey Chandrasekaran]

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> 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
> 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 
> 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
>>
>
   zmq_pollitem_t sample_poller[] = { {rep_sock, 0, ZMQ_POLLIN, 0} };

int len_of_poller = (int)(sizeof(sample_poller) / sizeof(zmq_pollitem_t));

rc_poll = zmq_poll(sample_poller, len_of_poller, 0);
if (rc_poll > 0) {
if (sample_poller[0].revents & ZMQ_POLLIN) {
memset(, 0, sizeof(msg));
rc = zmq_msg_init();
if (rc < 0) {
goto poll_n_quit;
}

do {
rc = zmq_recvmsg(rep_sock, , ZMQ_NOBLOCK);
} while ((rc < 0) && (errno == EINTR));

if (rc < 0) 

Re: [zeromq-dev] libev and ZMQ

[Arun Athrey Chandrasekaran]

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  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

Re: [zeromq-dev] libev and ZMQ

[Arnaud Loonstra]

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] libev and ZMQ

[Arun Athrey Chandrasekaran]

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*
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
https://lists.zeromq.org/mailman/listinfo/zeromq-dev