<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Feb 7, 2016 at 2:31 PM, Alexander Petrovsky <span dir="ltr"><<a href="mailto:askjuise@gmail.com" target="_blank">askjuise@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>I have only two ideas:</div><div>- trap_exit, catch EXIT message and terminate</div><div>- call gen_server(XPid|YPid|ZPid) from terminate callback in every process, but it causes 'little temporary' deadlock.</div><span class="HOEnZb"></span></blockquote></div><br>When you have a simple way to close down the process chain, you can often just terminate it gracefully and message the others you are done. If you terminate abnormally, the links will make sure to reap the process tree.</div><div class="gmail_extra"><br></div><div class="gmail_extra">When you cannot close down the process chain in this way easily though, there are monitors. Call erlang:monitor(process, Pid) and handle the 'DOWN' message which arrives in your inbox. Monitors are unidirectional, so you will have to monitor those processes you need to watch out for individually. But this is the common way to handle termination by means of an async exception. Also, note the semantics of monitors if the Pid you monitor isn't there. And that you can call erlang:demonitor(MonitorRef, [flush]) to linearize monitor messages in your inbox. All in all the API is nice to work with in a safe way with a bit of attention.<br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">J.</div>
</div></div>