supervision

[Samuel Gaist]

On 5 août 2014, at 22:34, Aaron J. Seigo <aseigo at kde.org> wrote:

> On Tuesday, August 5, 2014 17.34:43 Marco Martin wrote:
>> On Monday 04 August 2014, Aaron J. Seigo wrote:
>>> One point I'm still very undecided on, however, is supervisors that run
>>> user functions: currently in the design supervisors are processes which
>>> are entirely defined and managed by the funq compiler and runtime. This
>>> keeps is simple. It could be possible to allow supervisors to also run a
>> 
>> could this cause a supervisor that supervises a supervisor that supervises a
>> supervisor.. 
> 
> supervisors that supervise other supervisors is a common pattern in Erlang and 
> is already allowed for in the current funq conceptual design. this allows one 
> to have different supervision policies for different sets of processes while 
> still having a single "top" process that you can stop to stop the entire 
> application.
> 
> in any case, having user code also running in the supervisor does make it more 
> complex and it certainly opens up more possibilities for the user to "get it 
> wrong". this is why i'm really on the fence with whether to allow this or not.
> 
> unless i can find a really compelling use case, i'm probably going to leave it 
> out at least for now and add it later if it turns out to be actually useful.
> 
> i do like the "cleanliness" of having supervisors do only that: supervise.
> 

+1 for the cleanliness. 

Is there any limit on how deep a supervisor tree can/should go ?