[erlang-questions] Newbie question--workers starting supervisors
Wed Apr 18 12:19:31 CEST 2007
>There is a cleanup function, if your processes
>are e.g. gen_servers. It's called terminate(Reason, St),
>and is called before the server terminates.
Yes, but the supervisor doesn't IIRC. This would be a good place to do something that logically should not be known by the worker process. An example could be a counter application for statistics which could be called from the "cleanup" function instead of from the crashing process, which is more logical from a hierarchical pov.
Not saying that the generic supervisor isn't good, simply stating it could be even better ;)
There is a cleanup function, if your processes
are e.g. gen_servers. It's called terminate(Reason, St),
and is called before the server terminates.
If the process terminates due to cascading EXITs,
it must trap exits in order for the terminate/2
function to be called.
The supervisor behaviour does have a flaw, in that
the restarted process has no way of knowing whether
it is started for the first time or for the nth
time, or whether the restart is part of an escalated
recovery. I think this severely reduces the benefit of
escalated restarts. While there are workarounds, e.g.
starting a "sentry" process last, which does nothing
but tell the others if it has been restarted, it would
be better if the supervisor could make restart info
I made such a supervisor once:
>From now on, I think I'll let it rest in peace in
the google archives - no need to mention it again.
> -----Original Message-----
> From: erlang-questions-bounces@REDACTED
> [mailto:erlang-questions-bounces@REDACTED] On Behalf Of Mazen
> Sent: den 17 april 2007 20:54
> To: erlang-questions@REDACTED
> Subject: [erlang-questions] Newbie question--workers starting
> True! Yes you can... but the argument that you can't know
> which process that crashed is still valid... however you have
> a very good point! And should probably have been the way I
> should have made it ^^
> On the other hand the supervisor forces you to do any cleanup
> in the start function that you configured in the childspec
> which can be a hassle because perhaps you want to clean
> something up and start up the new child in a known state.
> Actually that would be a good idea... the OTP team should
> implement a Cleanup function that is run if a child crashes :D
> Adam wrote:
> Well, you could alternatively create 10 unique child specs?
> (end of quote)
> Post sent from http://www.trapexit.org
> erlang-questions mailing list
erlang-questions mailing list
Post recived from mailinglist
(end of quote)
Post sent from http://www.trapexit.org
More information about the erlang-questions