[erlang-questions] gen_server message queue length increasing

[Magnus Klaar]

Hi!

On the verge of very off topic.

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.

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?

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.

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.

MVH Magnus

On Sat, Nov 5, 2011 at 12:44 AM, Jon Watte <jwatte@REDACTED> wrote:

> 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.
>>
>
>
> 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?
>
> 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?
>
> Sincerely,
>
> jw
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20111105/f76cc3ef/attachment.htm>