[zeromq-dev] Stopping zmq_device

[Martin Sustrik]

Jon Dyte wrote:
> 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...

As for the problem of exiting the devices what about this dumb patch:

http://github.com/sustrik/zeromq2/commit/11891ddd5577321a351a1850d28478e97f4b9162

What it does is that when context is terminated (zmq_term) all the 
associated devices exit with ETERM error.

The patch is in my private repo only so far but it can be merged into 
the trunk easily.

>> 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).

Yes. This can be done, but killing a socket from a different thread is 
kind of ugly. Any use cases for that aside of stopping the devices?

>> 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.

My feeling is that the long term goal for devices should be to run them 
in I/O threads instead of usurping the application threads. The 
rationale is that having large amount of devices requires large number 
of OS threads. Something more lightweight is needed and adding a device 
as just another task to I/O thread scheduler may be the way to go.

Anyway, that's a long term prospect. My point is that at this point we 
are not able to get to final API/ABI/implemetation in a single leap. So 
let's rather do simple gradual improvements and see where it leads us.

> 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........

It's not the paid work per se. It's the problem of stable/experimental 
trees. There are people using 0MQ in production that would be badly 
disappointed if experimental work broke their environment. On the other 
hand there are developers that are held back, maintaining their own 
patches in their private repos because merging them would compromise 
stability of the trunk.

There's really no way out except for separating stable and experimental 
trees. This is an operational concern and it will be handled by iMatix 
(Pieter, correct me if I'm wrong). Till then we are bound to suffer from 
this stable/experimental schizophrenia.

>> And then then stop method just uses our new interrupt_socket method and ends
>> the device loop with a flag.

Martin