[zeromq-dev] zmq_poll versus zloop reactor: different semantics - how to resolve?
mail17 at mah.priv.at
Tue Sep 25 21:51:04 CEST 2012
I have ZMQ_POLLPRI and ZMQ_POLLHUP working fine so far if poll() is used
however, I see no way to detect a pipe write side hangup with select() without doing a read() in zmq.cpp, which suggests to:
- drop ZMQ_POLLHUP and subsume it under ZMQ_POLLERR as before
- document the behaviour, meaning if a handler reading from a named pipe gets a ZMQ_POLLERR it should attempt a read(); if the read() returns 0 then it was in fact a hangup and the pipe should be closed and reopened, and the poller reestablished with zloop_poller_end () and zloop_poller().
In summary, this would mean that libzmq and czmq can detect and support OOB data on a file descriptor with zloop() as well as zmq_poll(), and deal with sysfs notifications and named pipes properly.
Am 25.09.2012 um 12:36 schrieb Michael Haberler:
> 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.
> - Michael
> 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
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
More information about the zeromq-dev