[zeromq-dev] about using ZMQ_FD in an external select loop
diffuser78
diffuser78 at gmail.com
Fri Sep 7 01:24:43 CEST 2012
I did not frame my question correctly and subject was misleading too. Let
me put that correctly.
I am using a ZMQ FD in an external select() loop, i,.e, a ZMQ FD is added
to the set of fds (regular unix fds) in an external select() loop.
Consider a situation, for a given message (in a router dealer pattern),
only a few bytes are received at the receiver end and not the complete
message, so the external select() loop would wake up the ZMQ FD since it
can read atleast few bytes, but when we call zmq_getsockopt() API with an
option of ZMQ_EVENTS to get the list of events on the socket, ZMQ doesn't
return any FD since no complete message is recvd (only a few bytes have
been recvd). My question is:
During the next select() iteration, would external select() wake up ZMQ FD
again because we did not read the few bytes that were ready to be read on
that fd OR will it NOT wake up ZMQ FD until new bytes are available for
reading on this fd? What is ZMQ behavior in this case.
Any help is greatly appreciated.
Thanks.
On Wed, Sep 5, 2012 at 5:41 PM, diffuser78 <diffuser78 at gmail.com> wrote:
> Hi,
>
> I am using a ZMQ FD in an external select() loop, that is, a ZMQ FD is
> added to the set of fds (regular unix fds) in an external select loop.
>
> Consider a situation, for a given message (in a router dealer pattern),
> only a few bytes are received at the receiver end and not the complete
> message, so the external select() loop would wake up the ZMQ FD since it
> can read atleast few bytes, but when we do a ZMQ_POLL, ZMQ doesn't return
> any FD since no complete message is recvd (only a few bytes have been
> recvd). My question is:
>
> Next time, would external select() wake up ZMQ FD again because it is
> level triggered or does ZMQ internally reads those bytes so that external
> select loop won't wake up ZMQ FD until new set of bytes are received ?
>
> Please let me know your thoughts.
>
> DJ
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20120906/d081d989/attachment.htm>
More information about the zeromq-dev
mailing list