[zeromq-dev] zmq_reactor API question

[Matt Weinstein]

Right, although you don't want to do any real work on that thread, so  
you'd create another thread to generate a heartbeat message down a  
pair or pub/sub socket, which you would also poll, and which would  
trigger stats collection and transmission.

If you need to do computational work, you pass it to a paired thread  
to handle it, and it gets shipped back when done (I've avoided REQ/REP  
because they hang the device, so you have to be content with streams).

There are pair helper routines in zmq_reactor_pair.h/cpp.

On Aug 11, 2010, at 5:01 PM, gonzalo diethelm wrote:

> Let me see if I understand you correctly. After playing around with  
> the way I want to implement a processing pipeline, I have realized I  
> will need the following in each node (all of this running in one  
> thread in one process):
>
> 1.     A pull socket to receive incoming requests.
> 2.     An inproc req/rep pair, to pass things from the “receiving  
> front-end” to the “processing back-end” (I do this to create the  
> illusion of synchronous processing when in reality everything is  
> asynchronous underneath).
> 3.     A push socket to pass requests down the pipeline.
> 4.     A pub socket to periodically publish a heartbeat and  
> statistics.
> 5.     A sub socket to subscribe to administrative commands.
>
> I guess the idea is that I could create this “mega-device” using  
> zmq_reactor?
>
>
> Gonzalo Diethelm
>
> From: zeromq-dev-bounces at lists.zeromq.org [mailto:zeromq-dev-bounces at lists.zeromq.org 
> ] On Behalf Of Matt Weinstein
> Sent: Wednesday, 11 August, 2010 16:54
> To: 0MQ development list
> Subject: Re: [zeromq-dev] zmq_reactor API question
>
> ØMQ devices are ordinarily used to connect two sockets to e.g. solve  
> the back-to-back bind problem, or to perform other simple transfer  
> operations.
>
> You can construct more complex devices yourself by building the poll  
> vectors and doing the housekeeping.  These devices can be used for  
> things like timeout/recovery, server pooling, failover, load  
> balancing, etc.
>
> zmq_reactor is a helper library that implements an event driven  
> (callback/reactor) paradigm on top of zmq_poll(), offering support  
> for simple polling strategies (priority order, downstream polling,  
> etc.)
>
> I consider it a first generation model, but it's pretty useful as it  
> stands.
>
> Best,
> Matt
>
> On Aug 11, 2010, at 4:28 PM, gonzalo diethelm wrote:
>
>
> Matt, allow me to reply with a request: could you provide a little  
> more information on what the use case for zmq_reactor is? I reviewed  
> the samples on the git repo but I am not sure exactly what your  
> goals are with the code (at a very high level). Forgive my being  
> obtuse…
>
> Thanks and best regards.
>
> Gonzalo Diethelm
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20100811/0d242c37/attachment.htm>