why catch gen_server; MOD:handle_call?

Ulf Wiger (AL/EAB) ulf.wiger@REDACTED
Thu Jul 8 12:52:56 CEST 2004


I would suggest that terminate/2 be used only to do 
'obvious' cleanup, i.e. the stuff you'll want to do 
before a normal shutdown. This could involve explicitly
closing files that are open, unloading mibs, etc.

Cleaning up possible inconsistencies should be done 
after restart, even though telling the difference between
a normal start and a restart after error might be tricky.

/Uffe

> -----Original Message-----
> From: owner-erlang-questions@REDACTED
> [mailto:owner-erlang-questions@REDACTED]On Behalf Of Matthias Lang
> Sent: den 8 juli 2004 10:08
> To: Martin J. Logan
> Cc: erlang-questions@REDACTED
> Subject: Re: why catch gen_server; MOD:handle_call?
> 
> 
> Hi,
> 
> Martin Logan writes:
> 
>  > The terminate function is called when a call back in a gen 
> server fails.
>  > I am wondering if this is a good idea or not.
> 
> You have a good point.
> 
> Inspired by your post, I took a quick look through the terminate
> functions in a system we wrote. I found a couple of 'terminates' which
> use information from the State variable to un-do side effects, even
> though the State variable is no longer reliably represents those side
> effects. Bad.
> 
> Moving the cleanup to a supervisor would discourage that type of
> mistake, but the canned supervisors don't have any mechanism for a
> process-specific cleanup. I'm not convinced they should,
> either. Putting the cleanup code in the same module as the server
> doesn't seem horrible, as long as you remember that you can't always
> rely on the State variable being at true reflection of system state.
> If you write code like this you're fine:
> 
>   terminate(normal, State) ->
>         % do anything you want, the State is consistent with the world
>         ok;
> 
>   terminate(shutdown, State) ->
>         % do anything you want, the State is consistent with the world
>         ok;
> 
>   terminate(Reason, Possibly_old_state) ->
>         % keep in mind that the State is not necessarily consistent
>         % with what has happened; the gen_server may have terminated
>         % while partway through a callback.
>         ok
> 
> I don't remember if they teach that in the advanced OTP course
> (Francesco? Lennart?). Changing the emacs skeleton would be a
> nudge in the right direction.
> 
> Matthias
> 



More information about the erlang-questions mailing list