[zeromq-dev] zmq_poll versus zloop reactor: different semantics - how to resolve?
mail17 at mah.priv.at
Tue Sep 25 12:36:18 CEST 2012
I am heading towards a solution, but it involves more than just conditionally ignoring POLLERR in zloop.c - that's easy (new ZMQ_IGNERR flag in pollitem.events and handling code).
The tough cases involve zmq.cpp - the revents coming back are too aggregated to handle these cases properly; currently every flag in revents which isnt a POLLIN|POLLOUT is returned as a ZMQ_POLLERR.
The missing ZMQ_POLL* bits are:
POLLHUP: this is signaled when a named pipe write side is closed, and zloop was monitoring the read side. Can only be handled by closing/reopening the fifo.
POLLPRI (OOB data): signaled by a kernel sysfs_notify() operation on a sysfs path. Can be handled by doing an lseek(fd,0,SEEK_SET) and read(fd,..) without closing/reopening.
To handle those, I'd #define ZMQ_POLLPRI and ZMQ_POLLHUP as bits if the underlying platform has them, else zero
However, there's a user-visible API change because the definition of ZMQ_POLLERR changes to:
revents & ~(POLLIN | POLLOUT | POLLPRI | POLLHUP)
meaning: a POLLHUP or POLLPRI on the underlying fd so far reported ZMQ_POLLERR; it will post-change report separate ZMQ_POLLHUP and ZMQ_POLLPRI bits instead of ZMQ_POLLERR. Also, code which uses these bits on a Unix platform will fail on, say, Windows, which I cant test here.
still want me to go ahead with this? I cant quite judge the impact of this change. I'm happy to do the changes, test for Linux, document them and add a test program.
ps: I said 'I did the prototype with libzmq - which worked fine' which in reality wasnt the case.
Am 24.09.2012 um 21:41 schrieb Pieter Hintjens:
> On Mon, Sep 24, 2012 at 2:00 PM, Michael Haberler <mail17 at mah.priv.at> wrote:
>> I have an application where a named pipe, and a sysfs device is monitored. I did the prototype with libzmq - which worked fine - and the switched to czmq, which broke things for me.
>> the issue is: czmq is too agresssive in shutting down a poll handler if a POLLERR is returned.
> Could be.
>> I dont like it, but am unsure what to do; fiddling with the inner loop of the reactor I dont feel confident about yet.
> It's a little involved but not so complex so my advice would be to
> look at the internals, propose a patch.
> You do want to provide a test case so people can see the before/after results.
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
More information about the zeromq-dev