supervisor - Erlang supervision and applications -

i have number of supervised components can stand alone separate applications. cascade them such call or event in worker in 1 component starts next component down in inverted tree-like structure.

1) can package each of these components separate applications? 2) if so,how write calling code start child application? 3) or need else altogether and,if so, what?

note: i'm still working on mastery of supervision trees. chain of events following application:start(mod) still not burned head.

many thanks,

lrp

supervision trees , applications complex erlang/otp concepts. both documented in otp design principles user's guide , in particular in:

• chapter 5: supervisor behaviour
• chapter 7: applications.

supervision trees not dependency trees , should not designed such. instead, supervision tree should defined based on desired crash behavior, desired start order. reminder, every process running long enough must in supervision tree.

an application reusable component can started , stopped. applications can depend on other applications. however, applications meant started @ boot-time, , not when event occurs.

processes can started when given event occurs. if such processes shall supervised, call supervisor:start_child/2 on supervisor when event occurs. start process , inserted in supervision tree. typically use simple-one-for-one supervisor have no child.

consequently:

1. you can package components separate applications. in case, declare dependencies of applications in each application's app(4) file. applications started in proper order, either boot script or interactively application:start/1.

2. you can package components in single application , have worker processes starting other worker processes supervisor:start_child/2.

3. you can package components separate applications , have worker processes in 1 application starting processes in application. in case, best define module in target application call supervisor:start_child/2 itself, applications should have clean apis.

when have worker processes (parents) starting other worker processes (children), will link processes. linking achieved link/1. links symmetric , established parent since parent knows pid of child. if parent process exits abnormally, child terminated, , reciprocally.

links common way handle crashes, example child shall terminated if parent no longer there. links foundation of otp supervision. adding links between worker processes reveals designing supervision trees difficult. indeed, links, have both processes terminating if 1 crashes, , yet, not want child process restarted supervisor, supervisor-restarted child process not known (or linked) supervisor-restarted parent process.

if parent shall terminate when child exits normally, totally different design. can either have child send message parent (e.g. return result) or parent monitor child.

finally, parent process can terminate child process. if child supervised, use supervisor:terminate_child/2. otherwise, can send exit signal child process. in either cases, need unlink child process avoid exit of parent process.

both links , monitors documented in erlang reference manual user's guide. instead of monitors, might tempted trap exits, explained in the guide. however, manual page function achieve (process_flag/2) reads:

application processes should not trap exits.

this typical otp design wisdom, spread here , there in documentation. use monitors or simple messages instead.