[erlang-questions] Associating contextual info with monitors

[Dave Peticolas]

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