[erlang-questions] supervisor started from gen_server

[Ahmed Omar]

Hi Mazen ,

One question rises here about this. What happens when the processes under
that supervisor reach the maximum number of restarts, and the supervisor is
terminated. In a "traditional" supervision tree, the higher level supervisor
shall react to that. In your case, it will be the gen_server which i imagine
will crash then?

On Fri, May 20, 2011 at 2:00 PM, Mazen Harake <mazen.harake@REDACTED>wrote:

> Of course you *can* but the point I'm trying to make is that it's not
> "wrong" to do it like I did and it doesn't break OTP behaviour and is
> actually convenient. Doing it like I did eliminates all the clean up code I
> have to make when starting and stopping when the supervisor is "parallel"
> rather than "under" my client process.
>
> As I said, in general you wouldn't want to do it like that but you *can*
> and it isn't *wrong* and it isn't a *hack*. The Erlang documentation doesn't
> (AFAIK) bring up this scenario but it doesn't make it less useful.
>
> That is all.
>
>
> On 20 May 2011 13:52, Kannan <vasdeveloper@REDACTED> wrote:
>
>> Mazen,
>>
>> You can do the same thing with simple_one_for_one supervisors, one_for_all
>> supervisors and one_for_one supervisors stacked in different levels.
>>
>>
>>
>>
>>
>> On Fri, May 20, 2011 at 2:55 PM, Mazen Harake <mazen.harake@REDACTED>wrote:
>>
>>> I don't agree with the "never" part. There are corner cases and I would,
>>> in general, absolutely agree with what you wrote but here is one example of
>>> an exception.
>>>
>>> In my IRC library (https://github.com/mazenharake/eirc) I have the
>>> following scenario:
>>>
>>> One can create 1..n clients. Each client is a process (running a
>>> gen_server in eirc_cl.erl). A client can have many processes associated with
>>> it, in my case these are called Bots. Each bot is started and supervised by
>>> a client. A bot shall not terminate unless told to do so (gracefully) or if
>>> the parent dies (i.e the client). Now if I manually start a supervisor
>>> instance inside the gen_server I can simply make use of the supervisor
>>> functionality without handling any of that in my gen_server. I can add and
>>> remove children (bots) dynamically from my supervisor I.e. I don't have to
>>> maintain my own list of them and when I (the client) exits my children (I.e.
>>> the supervisor) will exit and thus my bots will exit... all according to OTP
>>> principals and I don't need to catch exit signals. This makes it REALLY easy
>>> to clean up things since all I have to do is to close the client process,
>>> the client process doesn't even need logic in the terminate callback since
>>> the children will exit with the same reason. If my supervisor was "on the
>>> outside" (like you suggest and which it normally is) I would have to make
>>> sure to clean up after myself with the supervisor.
>>>
>>> So it is much simpler (from an isolation point of view) to (in my case)
>>> start a supervisor Inside the gen_server.
>>>
>>> never say never ;)
>>>
>>> /M
>>>
>>>
>>>
>>>
>>>
>>> On 18 May 2011 14:13, Vance Shipley <vances@REDACTED> wrote:
>>>
>>>> On Wed, May 18, 2011 at 11:38:50AM +0200, Roberto Ostinelli wrote:
>>>> }  just a quick question: can you think of any case in which starting a
>>>> }  supervisor from a gen_server would actually be a perfectly fit idea?
>>>>
>>>> Never.
>>>>
>>>>                      +---------+
>>>>                      | foo_sup |
>>>>                      +-+-----+-+
>>>>                       /       \
>>>>           +----------+--+   +--+---------+
>>>>           | bar_sup_sup |   | foo_server |
>>>>           +---+---------+   +------------+
>>>>               |
>>>>          +----+----+
>>>>          | bar_sup |
>>>>          +---------+
>>>>
>>>> Start a supervisor for the new dynamic supervisor(s) and use
>>>> supervisor:start_child/2 from the gen_server to start it.
>>>>
>>>> --
>>>>         -Vance
>>>> _______________________________________________
>>>> erlang-questions mailing list
>>>> erlang-questions@REDACTED
>>>> http://erlang.org/mailman/listinfo/erlang-questions
>>>>
>>>
>>>
>>> _______________________________________________
>>> erlang-questions mailing list
>>> erlang-questions@REDACTED
>>> http://erlang.org/mailman/listinfo/erlang-questions
>>>
>>>
>>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
>


-- 
Best Regards,
- Ahmed Omar
http://nl.linkedin.com/in/adiaa
Follow me on twitter
@spawn_think <http://twitter.com/#!/spawn_think>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20110520/b6c78ff3/attachment.htm>