[erlang-questions] Associating contextual info with monitors

[Dave Peticolas]

Ah, I understand now. Thanks for your patience!

dave

Ulf Wiger wrote:
> Yes, that's what I meant. I was typing in my response
> using my cell phone, and was perhaps a bit curt.
> 
> terminate() is always called when the callback throws
> an exception, but if the process receives an EXIT signal,
> it can only call terminate() if the EXIT signal doesn't kill
> it right away (i.e. it has to be trapping exits, and the exit
> reason must be something other than 'kill').
> 
> BR,
> Ulf W
> 
> 2008/2/23, Dave Peticolas <dave@REDACTED>:
>> 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
>>  >>
>>  >
>>
>>
>