[erlang-questions] gen_server message queue length increasing

[Jon Watte]

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.
Thanks for your description.

Sincerely,

jw


--
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.



On Fri, Nov 4, 2011 at 7:54 PM, Magnus Klaar <magnus.klaar@REDACTED> wrote:

> 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/29f2fb66/attachment.htm>