aboutsummaryrefslogtreecommitdiffstats
path: root/lib/stdlib/src/supervisor.erl
AgeCommit message (Collapse)Author
2011-10-28Handle undefined pid when reporting error from supervisorSiri Hansen
2011-10-20Merge branch 'cf/simple_one_for_one_shutdown'Henrik Nord
* cf/simple_one_for_one_shutdown: Explain how dynamic child processes are stopped Stack errors when dynamic children are stopped Explicitly kill dynamic children in supervisors Conflicts: lib/stdlib/doc/src/supervisor.xml OTP-9647
2011-10-10Allow an infinite timeout to shutdown worker processesChristopher Faulet
Now, in child specification, the shutdown value can also be set to infinity for worker children. This restriction was removed because this is not always possible to predict the shutdown time for a worker. This is highly application-dependent.
2011-10-07Add '-callback' attributes in stdlib's behavioursStavros Aronis
Replace the behaviour_info(callbacks) export in stdlib's behaviours with -callback' attributes for all the callbacks.
2011-09-16Stack errors when dynamic children are stoppedChristopher Faulet
Because a simple_one_for_one supervisor can have many workers, we stack errors during its shutdown to report only one message for each encountered error type. Instead of reporting the child's pid, we use the number of concerned children.
2011-09-16Explicitly kill dynamic children in supervisorsChristopher Faulet
According to the supervisor's documentation: "Important note on simple-one-for-one supervisors: The dynamically created child processes of a simple-one-for-one supervisor are not explicitly killed, regardless of shutdown strategy, but are expected to terminate when the supervisor does (that is, when an exit signal from the parent process is received)." All is fine as long as we stop simple_one_for_one supervisor manually. Dynamic children catch the exit signal from the supervisor and leave. But, if this happens when we stop an application, after the top supervisor has stopped, the application master kills all remaining processes associated to this application. So, dynamic children that trap exit signals can be killed during their cleanup (here we mean inside terminate/2). This is unpredictable and highly time-dependent. In this commit, supervisor module is patched to explicitly terminate dynamic children accordingly to the shutdown strategy. NOTE: Order in which dynamic children are stopped is not defined. In fact, this is "almost" done at the same time.
2011-08-30Merge branch 'dev' into majorHenrik Nord
2011-08-23fix supervisors restarting temporary childrenFred Hebert
In the current implementation of supervisors, temporary children should never be restarted. However, when a temporary child is restarted as part of a one_for_all or rest_for_one strategy where the failing process is not the temporary child, the supervisor still tries to restart it. Because the supervisor doesn't keep some of the MFA information of temporary children, this causes the supervisor to hit its restart limit and crash. This patch fixes the behaviour by inserting a clause in terminate_children/2-3 (private function) that will omit temporary children when building a list of killed processes, to avoid having the supervisor trying to restart them again. Only supervisors in need of restarting children used the list, so the change should be of no impact for the functions that called terminate_children/2-3 only to kill all children. The documentation has been modified to make this behaviour more explicit.
2011-06-17Handle exit reason {shutdown,Term} as shutdown for children of supervisorSiri Hansen
In R13B proc_lib, gen_server and gen_fsm were all changed to handle exit reason {shutdown,Term} in the same way as exit reason 'shutdown', i.e. no crash reports are generated. This is an update of supervisor to do the same, i.e. handle these two exit reasons in the same way. This means that for children with restart type 'transient' there will be no attempt to restart the process if it terminates with reason {shutdown,Term}, and there will be no supervisor report.
2011-05-12Types and specifications have been modified and addedHans Bolinder
2011-05-04Change list to set in supervisor for saving pids of dynamic temprary childrenSiri Hansen
Since initial arguments of temporary children under simple_one_for_one supervisors are not saved, only a list of pids was stored in such supervisors. When adding/deleting many children, this would scale badly. To avoid this the list is now changed to a set.
2011-04-12Allow supervisor:terminate_child(SupRef,Pid) for simple_one_for_oneSiri Hansen
supervisor:terminate_child/2 was not allowed if the supervisor used restart strategy simple_one_for_one. This is now changed so that children of this type of supervisors can be terminated by specifying the child's Pid.
2011-04-04Completed bug fix "temporary child specs should not be kept when childIngela Anderton Andin
terminates" and improved test suite The bug fix supplied by Filipe David Manana <[email protected]> did not cover all possible ways that a process may be terminated as for instance with supervisor:terminate_child. Also there was a bug in the base case of the patch returning a list of a list instead of only the list. Added a timeout for the test cases, eliminated unnecessary sleeps, improved code.
2011-04-04Fix issue with temporary children introduced by OTP-9064Filipe David Manana
The temporary child specs are never removed from the supervisor's state, and have they're MFA component set to {M, F, undefined} instead of the MFA passed in the supervisor:start_child/2 call. Subsequent calls to supervisor:restart_child/2 may crash. Stack trace example: {badarg,[{erlang,apply,[gen_server,start_link,undefined]}, {supervisor,do_start_child,2},{supervisor,handle_call,3}, {gen_server,handle_msg,5}, {proc_lib,init_p_do_apply,3}]}
2011-02-22Added test case do_not_save_start_parameters_for_temporary_children and fixedIngela Anderton Andin
dialyzer spec.
2011-02-22Do not save parameter list for any temporary processesIngela Anderton Andin
Previous commit changed the supervisor to not save parameter lists for temporary processes supervised by simple-one-for-one supervisors. But it is unnecessary to save them for any temporary processes as they should not be restarted. Proably the biggest gain is in the simple-one-for-one case. Also changed the test case count_children_memory so it does not test that which_children will produce garbage that must be reclaimed later. This is a strange thing to test and it is no longer true for all invocations of which_children.
2011-02-22Do not save initial arguments for dynamic temporary processesIngela Anderton Andin
2010-11-22Remove superfluous supervisor error reportBjörn-Egil Dahlberg
2010-10-14supervisor: Type and spec related changesKostis Sagonas
- Export two more types so that they can be used in other modules - Correct some types and specs - Add spec for behaviour_info/1
2010-06-03Add declaration for exported typesKostis Sagonas
2010-06-03Add types and specs; performed some cleanups alsoKostis Sagonas
2010-02-12Merge branch 'jn/supervisor_child_count_only' into ccase/r13b04_devErlang/OTP
* jn/supervisor_child_count_only: Add count_children/1 to supervisor.erl to determine the number of OTP-8436 Added supervisor:count_children/1 to count the number of children being managed without the memory impact of which_children/1. (Thanks to Jay Nelson.)
2010-02-10Add count_children/1 to supervisor.erl to determine the number ofJay Nelson
children being managed without the memory impact of which_children/1 The function which_children/1 returns a list of the child processes currently being supervised, but it has the penalty of creating a new list thereby consuming more memory. In low memory situations it is often desirable to know which supervisor may have generated many processes, but the act of discovering the culprit should not cause the node to crash (or worse a different node if the kernel kills one randomly). The new function count_children/1 can give an indication of which supervisor is taxing resources the most without adding to the burden. Rather than creating a new list, it walks the supervisor's internal children structure using an accumulator function so that any used memory can be incrementally collected yet the resulting count can still be obtained. The return result of count_children/1 is a property list of counts containing: - {specs, Total_Num_Child_Specs} - {active, Num_Active_Child_Processes_Of_Supervisor_Or_Worker_Type} - {supervisors, Num_Supervisor_Type_Children_Including_Dead_Processes} - {workers, Num_Worker_Type_Children_Including_Dead_Processes} This patch was made in response to mailing list discussions of the problem diagnosing heavily taxed production systems. I cannot find the original request, but http://www.erlang.org/cgi-bin/ezmlm-cgi/4/35060 is my original post of the patch.
2009-11-20The R13B03 release.OTP_R13B03Erlang/OTP