I am building a threaded file monitoring tool using zmq and inotify. I discovered that I will have a nasty block when I want to end a thread that is currently blocking while watching a file.
Since I am solving similar problems of threads waiting for zmq messages with a double polling on two separate endpoints, one being the actual endpoint and the other being a custom SIGTERM-message broadcast from the main thread, I was wondering if I could do the same here. As I want to solve all thread synchronisation problems using such polling and zmq messages (stearing clear of stuff like mutexes and signals), this seems to be a good go. I dived into the code and realized that the zmq_poll() is basically a wrapper for the system's poll() function, which is also the suggested polling method for inotify. I went ahead and simply added inotify's file descriptor (fd) as an item to my zmq::pollitem_t array (passing a 0 as the socket): { 0, fd, ZMQ_POLLIN, 0 } This seems to work quite well actually! Now I wanted to ask if this is okay for production use. I even let the ZMQ_POLLIN in, as I am not sure if zeromq's polling will handle the system's POLLIN well enough, but the inverse may just as well be true? So is it advisable to just shove the fd of inotify into zmq's polling function? Thanks! alex. _______________________________________________ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev