[erlang-bugs] Strange behaviors in supervisor module.

Siri Hansen <>
Fri Jun 17 12:28:26 CEST 2011


The strange behaviors that you have discovered are really the expected
behaviors. However, I do agree that the documentation is a bit incomplete on
these issues.

In f_sup1, after killing the child process, I try to delete it by calling
> supervisor:delete_child, it returns {error,running}.

This is a timing issue - since exit/1 is asynchronous, delete_child/2 will
be called before the process is actually terminated.
However, if you add an appropriate timer:sleep(...) between the two calls,
you will get {error,not_found} instead. This is because a temporary child is
automatically deleted when it terminates, since such processes can never be
restarted anyway.

In f_sup2, if a child processes exits with reason normal, a temporary child
> process cannot be restarted, but transient process can. So f_sup2
> returns{{error,not_found},{ok,<0.364.0>}}. This seems inconsistent because a
> transient process that exits with reason normal is not supposed to be
> restarted.

It is correct that a transient process which terminates with reason normal
is not automatically restarted by the supervisor. However, it is still
possible to explicitly restart it by calling supervisor:restart_child as
long as you have not deleted the child spec by calling
supervisor:delete_child. Only temporary processes can not be restarted this

> In f_sup3, if a transient child process exits with the reason shutdown, it
> won't be restarted. It seems strange, since, a transient child process
> should be restarted unless it is terminated with the reason normal.

The exit reason 'shutdown' has a special meaning in OTP - it is the exit
reason used by a supervisor when terminating its children. Obviously, the
child shall not be automatically restarted after such termination.

I will have a look at the documentation and try to make it more clear.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-bugs/attachments/20110617/cb1b34d8/attachment.html>

More information about the erlang-bugs mailing list