[zeromq-dev] Ideas for a zfork class

[Pieter Hintjens]

Also, Zyre now supports IPC and inproc between nodes, if you use the
gossip discovery feature.

One of my goals eventually is to allow actors to start as external
processes, connected over IPC. However there's a non-trivial layer of
process control involved.

So I think your idea is a good one (I don't like the name as "fork" is
a Unixism and doesn't really help).

https://github.com/savke/ztask0 may help, Martin Vala has been working
on this problem for a while.

-Pieter

On Tue, Sep 2, 2014 at 4:56 PM, Rodrigo Mosconi <mosconi.rmg at gmail.com> wrote:
>
> Hi Chad
>
> On Tue, Sep 2, 2014 at 11:32 AM, Chad Koski <chad at koski.com> 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.
>>
>
> I need something machine "local".  An example of behavior: postgresql.  The
> PG has a master process, and on a new user connection, it spawn a worker to
> do all the works for that connection.   I need to do something like that.
>
>>
>> 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
>> 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
>> _______________________________________________
>> 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
>>
>
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>