[zeromq-dev] missing events ZMQ_FD / ZMQ_EVENTS

Gerhard Lipp gelipp at googlemail.com
Fri Apr 27 10:41:18 CEST 2012


On Fri, Apr 27, 2012 at 10:29 AM, Paul Colomiets <paul at colomiets.name> wrote:
> Hi Gerhard,
>
> On Thu, Apr 26, 2012 at 10:02 AM, Gerhard Lipp <gelipp at googlemail.com> wrote:
>> Hello Paul!
>>
>> On Wed, Apr 25, 2012 at 8:29 PM, Paul Colomiets <paul at colomiets.name> wrote:
>>> Hi Gerhard,
>>>
>>> On Wed, Apr 25, 2012 at 6:08 PM, Gerhard Lipp <gelipp at googlemail.com> wrote:
>>>> i figured out to boil down an example, which shows this bug.
>>>> it consists of three files:
>>>> 1) x.lua doing the XREP XREQ stuff, must be started once
>>>> 2) rep.lua implementing a simple echo replier, must be started once
>>>> 3) req.lua making the request to rep.lua through x.lua. must be
>>>> started TWICE to produce the error. THIS PROCESS LOCKS. uncommenting
>>>> the ev.WRITE is a bad workaround to this issue.
>>>
>>> As far as I can see, it not a workaround. It's just the way ZMQ_FD works.
>>> Uze zmq_poll if you don't feel comfortable for that. The only way you can change
>>> that is returning getopt(zmq.EVENTS) instead of hardcoding ev.READ + ev.WRITE
>>>
>>
>> According to the manual, the fd returned by zmq_getsockopt(ZMQ_FD)
>> "signals any pending events on the socket in an edge-triggered fashion
>> by making the file descriptor become ready for reading".
>>
>> If ev.WRITE is required to get all ZMQ_POLLIN and/or ZMQ_POLLOUT
>> events, the doc should be clearer. Anyhow, as the source looks like,
>> the ZMQ_FD is the fd associated with the socket's "mailbox", which is
>> used for all kinds communication (state transitions?) inside of ZMQ. A
>> "selecting/polling" user process should not wake up unnecessarily to
>> avoid context switches, which are really expensive on our (embedded)
>> device. Thus i'd like to minimize the wakeups by just specifying
>> ev.READ.
>>
>
> Probably I don't understand the code. You must poll only for reading
> on ZMQ_FD. But every zmq_send and zmq_recv cosumes mailbox.
> Which means you must update you applications' state of readable
> and writable flags (I mean your IO framework doesn't know that
> socket became readable or writable).
>
> If you don't care about ZMQ_POLLOUT event, you still must check
> ZMQ_EVENTS for reading on each zmq_send.

You are right, I am actually just waiting to be able to zmq_recv with
ZMQ_NOBLOCK. I dont care about the ZMQ_POLLOUT in this example. As the
docs state, either event is signaled by the mailbox (ZMQ_FD) becoming
ready to read (ev.READ). That is why i am checking for ZMQ_POLLIN
before entering the zmq_recv/zmq_send.


>
> --
> Paul
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev



More information about the zeromq-dev mailing list