[erlang-questions] Associating contextual info with monitors

[Dave Peticolas]

Ulf Wiger wrote:
> No, terminate() is always called, if possible. If the server isn't
> trapping exits, the server may die without being able to do any
> cleanup.

Thanks for your answer. Now trapping exits is required for terminate
to be called, right? The gen_server docs seem to indicate this.

In my testing, it seems like terminate is only called if the
gen_server is trapping exits, even if it is a 'normal' shutdown.

thanks,
dave


> BR,
> Ulf W
> 
> 2008/2/20, Dave Peticolas <dave@REDACTED>:
>> Rick Pettit wrote:
>>> On Sun, Feb 17, 2008 at 07:52:56PM -0700, Dave Smith wrote:
>>>> Greetings,
>>>>
>>>> On several occasions, I've found myself wanting to be able to do some
>>>> cleanup (e.g. remove an entry in ets) when a process dies. Usually I
>>>> solve this by maintaining an ets table keyed by pid, that stores the
>>>> necessary contextual info needed for cleanup, and then setup a monitor
>>>> on the pid of interest. This works ok, but it's a little annoying to
>>>> need to maintain yet another ets table for this context info that is
>>>> only used when the process dies. It seems like what I _really_ want is
>>>> a way to associate a term with a monitor -- that way when I get the
>>>> DOWN message, I would also get the associated term and have everything
>>>> I need to do the cleanup.
>>>>
>>>> Is there a "Right Way" to accomplish this? Maintaining ets tables for
>>>> this sort of contextual info seems a bit overkill -- is there a
>>>> simpler approach? Has anyone else ever encountered this sort of issue?
>>>> I tried searching through the archives for this problem, but couldn't
>>>> find the right set of search terms. :)
>>> The way I typically solve this problem is by putting the cleanup code in
>>> a gen_server:terminate/2 callback (this way when the gen_server dies it
>>> cleans up after itself).
>> Now I thought that terminate/2 is only called when a gen_server requests
>> a stop from a callback function (by returning {stop, ...}), but not when
>> it dies from, say, an exception. Is that not right?
>>
>>
>>> For instances where the processes being spawned aren't gen_* servers, I
>> would
>>> most likely spawn a wrapper process which in turn spawn_links the real
>> child
>>> process, then blocks forever waiting to receive the EXIT for that process
>> (the
>>> cleanup code is triggered upon receipt of the EXIT, then the wrapper
>> process
>>> itself terminates).
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://www.erlang.org/mailman/listinfo/erlang-questions
>>
>