[zeromq-dev] Stopping zmq_device

[Jarred Ward]

>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20100702/43b448ed/attachment.htm>