> > Please see my previous post, add a third socket to the invocation of > the streamer, wait for something to be sent to that socket, then exit...
Yeah that would work, but as it stands the streamer/queue/forwarder aren't built on polling. I imagine they could be pretty easily, but I like how conceptually simple they are now. I don't know, something just kind of smells with having to add an extra command socket when we already have a "command" infrastructure in zmq; although it's not directly exposed to the outside world. Either way, I simply was trying to point out in this thread that as the code is zmq_device will *never* return -- no matter what as it is. Now I'm going to bleed into the blocking conversation. I only have a cursory understanding of the code base, but bear with me on my stream of thought here. zmq_term just sends stop commands to every app thread. I'm thinking we add a "interrupt" command into the command infrastructure. Then we could have something like this: zmq::ctx_t::interrupt(socket) This method would then find the app_thread associated with the socket and interrupt any blocking calls. This would cause an pending recv's to return EIR (interrupt request). Back to the devices. If we built a device base class like this: zmq::device_t::device_t(int type, void *insocket, void *outsocket) zmq::device_t::start() zmq::device_t::stop() And then then stop method just uses our new interrupt_socket method and ends the device loop with a flag. Jarred
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
