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
