[zeromq-dev] Stopping zmq_device

Jon Dyte jon at totient.co.uk
Sun Jul 4 12:00:13 CEST 2010


Jarred Ward wrote:
>> 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()
>   

funnily enough the device's were initially a class when I submitted the 
patch, but after review with Martin , plus
the idea that this was experimental, it was stripped down to just the 
function, whilst the exact requirements are worked out, thru
discussion on the list, which is why this discussion is interesting. One 
of the constraints is that it must be able to work as C api.
It does sound like there is a need for a 'control' socket to be added, 
plus other people wanted to be able to use the devices
in there own zmq_poll loop.

On another note I have branch with the standalone binary devices all 
combined into the same binary called zmqd , and you can put multiple 
forwarder, queue, streamer
all in the single process from the xml config file. I need to add the 
setsocket option stuff. This didnt make it into the 2.0.7 release and 
since then the
world-of-paying-work (which sadly doesnt involve 0MQ) has been getting 
in the way........


> 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
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>   




More information about the zeromq-dev mailing list