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. - Michael 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 <[email protected]> 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. >> >> -Pieter >> _______________________________________________ >> zeromq-dev mailing list >> [email protected] >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev > > _______________________________________________ > zeromq-dev mailing list > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
