[erlang-questions] supervisor started from gen_server

Mazen Harake mazen.harake@REDACTED
Fri May 20 15:16:56 CEST 2011 

Actually, it is exactly the opposite.

I can concentrate more on my application and less on what I need to clean up
after it (or even when it comes to maintaining it... I still have to go
through my client to achieve the bot handling).

The only difference, really, is that all the supervisors I'm creating could
be under a seperate "supervisor for bot_supervisors" but then I wouldn't
have the same isolation.

But my main point still is this: Don't say "Never", because sometimes it is
extremely useful.


On 20 May 2011 15:04, Kannan <vasdeveloper@REDACTED> wrote:

> You will have assume and concentrate on many other things other than
> concentrating on your application logic.
>
>
> On Fri, May 20, 2011 at 5:53 PM, Mazen Harake <mazen.harake@REDACTED>wrote:
>
>> Correct.
>>
>> A Bot (in this case) is seen as an extension of the client. Thus if the
>> bot (which by implication is the client) is misbehaving or enters a faulty
>> state the client crashes. The result of this is that the client is restarted
>> (and the corresponding bots are reset).
>>
>> /M
>>
>>
>> On 20 May 2011 14:19, Ahmed Omar <spawn.think@REDACTED> wrote:
>>
>>> 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/#%21/spawn_think>
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20110520/23cd7843/attachment.htm>

More information about the erlang-questions mailing list