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. Note if you do 'echo value >pipe', poll(2) returns a POLLIN (pipe readable), followed by a POLLER (pipe closed). When a sysfs entry is notified by the kernel by sysfs_notify(), a poll(2) returns with POLLERR and POLLPRI bits set. (see http://lwn.net/Articles/174660/) so in both cases, POLLERR doesnt signify anything abnormal. The zmq version works just fine with a logic like so; similar for the pipe case: zmq_pollitem_t items [] = { ... { 0, fd, ZMQ_POLLERR, 0 } }; .. if (items [1].revents & ZMQ_POLLERR) { // sysfs entry was signaled with sysfs_notify() lseek(fd, 0, SEEK_SET); len = read(fd, buf, sizeof(buf)); .... } Now with czmq, a POLLERR bit returned from poll2() within a zloop() reactor will disable the handler after the first POLLERR (zloop.c:401) meaning only the first pipe reabable/sysfs_notify() event will be handled. I've found a sledgehammer workaround: in the handler, close the device, deregister poller with zloop_poller_end (), reopen device, re-register with zloop_poller(). The net effect of this is to clear poller->errors so the handler isnt disabled after the first POLLERR. I dont like it, but am unsure what to do; fiddling with the inner loop of the reactor I dont feel confident about yet. any suggestions? - Michael _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
