[zeromq-dev] Stopping zmq_device

[Robin Weisberg]

Just curious what you mean by "I need to add the setsocket option stuff". Perhaps you are referring to the ability to set socket options from the xml config file? I think it would be a useful feature to have something in ZMQ (not just in the device) that can set the socket options from a string. E.g. 

s.setsockopt(ZMQ_SOCKOPTSTR,"ZMQ_RATE=1000;ZMQ_HWM=10000;ZMQ_LWM=2000");

In addition to being a useful function for the device to use when parsing its xml config file, anybody else who wants to set options based on a config file would find this useful.



-----Original Message-----
From: zeromq-dev-bounces at lists.zeromq.org [mailto:zeromq-dev-bounces at lists.zeromq.org] On Behalf Of Jon Dyte
Sent: Sunday, July 04, 2010 6:00 AM
To: 0MQ development list
Subject: Re: [zeromq-dev] Stopping zmq_device

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
>   

_______________________________________________
zeromq-dev mailing list
zeromq-dev at lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev