<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><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">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 class="im"><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>