[zeromq-dev] zmq_reactor API question
matt_weinstein at yahoo.com
Thu Aug 12 03:43:44 CEST 2010
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
> 5. A sub socket to subscribe to administrative commands.
> I guess the idea is that I could create this “mega-device” using
> 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
> 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,
> I consider it a first generation model, but it's pretty useful as it
> 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
> Thanks and best regards.
> Gonzalo Diethelm
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the zeromq-dev