That's what I had understood, too, but some people who I would trust were suggesting that I did too much work myself by keeping track of children in a separate process using links, and managing an ets table in that process -- the advice was that processes removing themselves in terminate() would be cleaner.<div>
Thanks for your description.</div><div><br></div><div>Sincerely,</div><div><br></div><div>jw</div><div><br><div><br>--<br>Americans might object: there is no way we would sacrifice our living standards for the benefit of people in the rest of the world. Nevertheless, whether we get there willingly or not, we shall soon have lower consumption rates, because our present rates are unsustainable. <br>
<br>
<br><br><div class="gmail_quote">On Fri, Nov 4, 2011 at 7:54 PM, Magnus Klaar <span dir="ltr"><<a href="mailto:magnus.klaar@gmail.com">magnus.klaar@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>Hi!</div><div><br></div><div>On the verge of very off topic.</div><div><br></div>First, even if you are not using the brutal_kill shutdown strategy, your server may be sent a kill signal by the supervisor if it does not terminate in a timely fashion when you are not using an infinite shutdown time.<div>

<br></div><div>So... now we have created ourselves a design that relies on workers trapping exits and a shutdown strategy that may hang the supervisor that the workers are running under indefinitely if we would ever need to stop a worker or restart the supervisor. Is the neatness of the terminate/2 callback worth this?</div>

<div><br></div><div>Second, even if one decides to go forward with this there is a second requirement for the terminate/2 callback being called, all of your other callbacks must be _guaranteed_ to return control back to the internal gen_server loop at some point, only if that loop receives an exit message from the parent process will your terminate/2 callback be called. Enter a deadlock somewhere or wait for a message that never arrives and this will break your assumption.</div>

<div><br></div><div>This counter example is a worst case scenario. Even if it should be rare, i see little sense in assigning a patient as the one responsible for performing its own post-mortem activities.</div><div><br>
</div>
<div>MVH Magnus</div><div><div></div><div class="h5"><div><br><div class="gmail_quote">On Sat, Nov 5, 2011 at 12:44 AM, Jon Watte <span dir="ltr"><<a href="mailto:jwatte@gmail.com" target="_blank">jwatte@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><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>It is not ok to let a gen_server delete itself because it is not guaranteed to delete the reference associated with it from the shared table. This approach will leak memory unless the child processes don't exit under ideal conditions.</div>



<div></div></blockquote></div><br><div><br></div></div><div>Is that *actually* true? Isn't the whole point of gen_server, and the Erlang VM in general, that you always have control, and thus can always run code, no matter what the fault?</div>


<div><br></div><div>Specifically, except for the brutal_kill termination kind, is there any case where a gen_server:terminate() callback that does an ets delete on a public table would ever fail?</div><div><br></div><div>


Sincerely,</div><div><br></div><font color="#888888"><div>jw</div><div><br></div>
</font></blockquote></div><br></div>
</div></div></blockquote></div><br></div></div>