[erlang-questions] simple-one-for-one

Keith Irwin keith.irwin@REDACTED
Sat May 23 20:08:01 CEST 2009


On Sat, May 23, 2009 at 10:57 AM, Kaiduan Xie <kaiduanx@REDACTED> wrote:

> Dave,
>
> What is the rationale to put the process under the simple-one-for-one
> supervision? If the process does not need to be-restarted when it
> terminates, there is no reason to supervise it. For the TCP connection
> or call, if something goes wrong and causes the process to die, we can
> just let it die without restarting the process.


It might be useful if you maintain a process pool for TCP connections. Say
you start up fifty processes all waiting on a socket accept (as in the
gen_tcp man page example). If each of those processes is supervised, they'll
be restarted if for some reason, they die. Right?

In my own code, I've not done this. Instead, I set trap_exit to true, then
handle re-spawns in my gen_server:info callback.

Until you asked your question, I hadn't even thought of using a supervisor
for that reason. Might that be a justification?

Keith



>
>
> Thanks,
>
> kaiduan
>
> On Sat, May 23, 2009 at 10:06 AM, Dave Smith <dizzyd@REDACTED> wrote:
> > On Sat, May 23, 2009 at 7:41 AM, Kaiduan Xie <kaiduanx@REDACTED> wrote:
> >> What is the typical usage for simple-one-for-one restart strategy? For
> >> example, for a call processing server we need to spawn a process for
> >> each call, do we need to put it under a simple-one-for-one supervision
> >> tree? The same question applies to a TCP server which spawns a process
> >> for each incoming TCP connection.
> >
> > Yup, that's how I generally use it. Any situation where you need many
> > (usually anonymous) instances of the same type of process is a good
> > fit for simple_one_to_one.
> >
> > D.
> >
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://www.erlang.org/mailman/listinfo/erlang-questions
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20090523/3ee91a32/attachment.htm>


More information about the erlang-questions mailing list