[zeromq-dev] Ideas for a zfork class

Goswin von Brederlow goswin-v-b at web.de
Wed Sep 3 14:18:23 CEST 2014

On Tue, Sep 02, 2014 at 10:32:21AM -0400, Chad Koski wrote:
> Hi Rodrigo,
> You might take a look at zyre (https://github.com/zeromq/zyre) to see what you can apply from there before adding a new class.  It might save you some work.
> zyre can handle the discovery, identification, heart beating and message passing between the master and worker (peers in the zyre network).   I?m not sure if it?s exactly what you are looking for, but if it gets you part of the way there, seems like it?s at least worth a look.  At the least, it should be able to give you some ideas on how to proceed if it?s not a good fit as-is.
> Chad
> On Sep 2, 2014, at 9:50 AM, Rodrigo Mosconi <mosconi.rmg at gmail.com> wrote:
> > Hi all,
> > 
> > I use a lot zthreads (I know that it`s deprecated, but I can`t change to zactor now) on a project.  But for some external reasons, I need to fork some zmq worker and I would like to manage this fork like zthread/zactor.  Let`s call it zfork, and I would like to exchange some thoughts before start developing it.
> > 
> > Some aspects that I already toughed:
> > 
> > 1 - master/worker intercomunication can`t rely on ZMQ_PAIR socket; maybe a ROUTER/DEALER over IPC approach could be better.
> > 2 - The master could generate a identification for the slave
> > 3 - presence of some sort of heart-beating

That basically means you want a zactor. The zactor then can fork the
process in turn and handle the heart-beating.

> > 4 - the master may act like a broker over the "control/parent-child" zsocket
> > 5 - if over IPC, the master could set filters (ZMQ_IPC_FILTER_...) on the socket
> > 
> > Any other ideas or comments?
> > 
> > Mosconi


More information about the zeromq-dev mailing list