aboutsummaryrefslogtreecommitdiffstats
path: root/lib/stdlib/doc/src/supervisor.xml
AgeCommit message (Collapse)Author
2012-03-30Update copyright yearsBjörn-Egil Dahlberg
2012-03-16Merge branch 'rj/fix-supervisor-shutdown-doc' into maintGustav Simonsson
* rj/fix-supervisor-shutdown-doc: Fix small typo in kernel app doc Cosmetic: split very long lines from supervisor doc Fix supervisor doc: Shutdown, MaxR and MaxT type specs Add the type restrictions in the code comments Remove trailing spaces OTP-9987
2012-03-05Leave control back to gen_server during supervisor's restart loopSiri Hansen
When an attempt to restart a child failed, supervisor would earlier keep the execution flow and try to restart the child over and over again until it either succeeded or the restart frequency limit was reached. If none of these happened, supervisor would hang forever in this loop. This commit adds a timer of 0 ms where the control is left back to the gen_server which implements the supervisor. This way any incoming request to the supervisor will be handled - which could help breaking the infinite loop - e.g. shutdown request for the supervisor or for the problematic child. This introduces some incompatibilities in stdlib due to new return values from supervisor: * restart_child/2 can now return {error,restarting} * delete_child/2 can now return {error,restarting} * which_children/1 returns a list of {Id,Child,Type,Mods}, where Child, in addition to the old pid() or 'undefined', now also can be 'restarting'.
2012-02-24Cosmetic: split very long lines from supervisor docRicardo Catalinas Jiménez
2012-02-24Merge branch 'uw/extending_gen' into maintGustav Simonsson
* uw/extending_gen: Add plugin support for alternative name lookup OTP-9945
2012-02-24Fix supervisor doc: Shutdown, MaxR and MaxT type specsRicardo Catalinas Jiménez
The next code snippets from supervisor.erl show that Shutdown from a child specification must be greater than zero and the same applies to MaxT. --- supervisor.erl ---------------------------------------------------------- validShutdown(Shutdown, _) when is_integer(Shutdown), Shutdown > 0 -> true; validShutdown(infinity, _) -> true; validShutdown(brutal_kill, _) -> true; validShutdown(Shutdown, _) -> throw({invalid_shutdown, Shutdown}). validIntensity(Max) when is_integer(Max), Max >= 0 -> true; validIntensity(What) -> throw({invalid_intensity, What}). validPeriod(Period) when is_integer(Period), Period > 0 -> true; validPeriod(What) -> throw({invalid_period, What}). -----------------------------------------------------------------------------
2011-12-20Don't save child spec for temporary child if child's start func returns ignoreSiri Hansen
Supervisor should never keep child specs for dead temporary children.
2011-11-24Add plugin support for alternative name lookupUlf Wiger
OTP behaviour instances (gen_server, gen_fsm, gen_event) can currently register themselves either locally or globally, and the behaviour libraries (including gen.erl) support both addressing methods, as well as the normal Pid and {Name, Node}. However, there are alternative registry implementations - e.g. gproc - and one can well imagine other ways of locating a behaviour instance, e.g. on a node connected only via a TCP tunnel, rather than via Distributed Erlang. In all these cases, one needs to write extra code to identify the behaviour instance, even though the instance itself need not be aware of how it is located. This patch introduces a new way of locating a behaviour instance: {via, Module, Name}. Module is expected to export a subset of the functions in global.erl, namely: register_name(Name, Pid) -> yes | no whereis_name(Name) -> pid() | undefined unregister_name(Name) -> ok send(Name, Msg) -> Pid Semantics are expected to be the same as for global.erl This can be used in all places where {global, Name} is accepted. faulty export in gen_fsm_SUITE.erl await process death in dummy_via:reset() fix error in gen_[server|fsm]:enter_loop() fix documentation
2011-11-16Improve documentation on supervisor restart strategySiri 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-10Add a warning to docs about workers' shutdown strategyChristopher Faulet
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-09-26Correct XML filesHans Bolinder
2011-09-16Explain how dynamic child processes are stoppedChristopher Faulet
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-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-05-12rHans Bolinder
Use Erlang specs and types for documentation
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.
2010-09-17Clarify documentation of shutdown timeout in supervisor child specsMagnus Henoch
Make it explicit that the shutdown timeout is to be specified in milliseconds.
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