<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Sat, May 14, 2016 at 9:46 AM, Chandru <span dir="ltr"><<a href="mailto:chandrashekhar.mullaparthi@gmail.com" target="_blank">chandrashekhar.mullaparthi@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Cleanup can be done in the terminate callback if you use process_flag(trap_exit, true). </blockquote></div><br>There is a subtlety here which, in some circumstances, creates trouble and one has to be aware of. This is in addition to what Loïc mentions.<br><br>Observation: In many systems, processes have dependencies and needs each other to operate. Nice cleanup cannot be done in the situation where your immediate dependencies are gone, but under a controlled shutdown, you can arrange the shutdown order such that the shutdown is graceful.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Example: You are processing some kind of request in a web server. You decide to close down the application. Now, what you want to happen is a graceful shutdown: you stop accepting new requests, but you run the current requests to an end (up to some timeout). In settings where the server count is very dynamic and servers can get "elastically" added or removed, this is important because otherwise you would be losing requests under shutdown.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Observation: processes under supervision have an ordering imposed on them. Their termination happens in the opposite order of spawning. This can be used to enforce the gracefulness constraint.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Another trick, which works cross-application, is to use the Module:prep_stop/1 phase of termination to tell your other applications (ranch, cowboy, yaws) that they should start graceful termination of their workers. Once completed, you can stop your own supervision tree.</div><div class="gmail_extra"><br></div><div class="gmail_extra">"Naked" processes which are not linked into a supervision tree can terminate in any order they see fit. In particular, the Erlang VM regards itself as being "done" once all its applications are shut down. In particular a line process with process_flag(trap_exit, true) waiting on disk is not going to be allowed to hold up termination of the VM. A naked process has its use, but one has to be extremely careful around them. If they start failing, you have no easy way to know what their relation is.</div><div class="gmail_extra"><div><br></div>-- <br><div class="gmail_signature">J.</div>
</div></div>