supervisor started from gen_server

[Roberto Ostinelli]

Hello all,

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? I tend to think of this with some relevant dose of fear, but I'd like to hear any opinion on this.

Thank you,

r.

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

[Dmitry Demeshchuk]

Sounds ridiculous. Supervisor should be started either by an
application as the root one, or by a higher-level supervisor. Most
likely, if you try starting it within gen_server, gen_fsm or whatever,
you'll end up with writing your own supervisor based on gen_server,
gen_fsm or whatever. Or you will have a failure point, which is as
bad.

On Wed, May 18, 2011 at 1:38 PM, Roberto Ostinelli <[hidden email]> wrote:

> Hello all,
>
> 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? I tend
> to think of this with some relevant dose of fear, but I'd like to hear any
> opinion on this.
>
> Thank you,
>
> r.
>
> _______________________________________________
> erlang-questions mailing list
> [hidden email]
> http://erlang.org/mailman/listinfo/erlang-questions
>
>

--
Best regards,
Dmitry Demeshchuk
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

[Vance Shipley]

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
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

[mazenharake]

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 <[hidden email]> 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
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

[Kannan]

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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

[mazenharake]

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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

[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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

--
Best Regards,
- Ahmed Omar

http://nl.linkedin.com/in/adiaa

Follow me on twitter

@spawn_think

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

[mazenharake]

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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

--
Best Regards,
- Ahmed Omar

http://nl.linkedin.com/in/adiaa

Follow me on twitter

@spawn_think

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

[Kannan]

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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

--
Best Regards,
- Ahmed Omar

http://nl.linkedin.com/in/adiaa

Follow me on twitter

@spawn_think

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

[mazenharake]

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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

--
Best Regards,
- Ahmed Omar

http://nl.linkedin.com/in/adiaa

Follow me on twitter

@spawn_think

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions