[erlang-questions] gen_server cleanup handling

[Bernard Duggan]

Hi Mazen,
     Our setup kind of has the opposite requirement - if either the 
worker or the gen_server that spawned it crash, both should crash out 
(sorry, that probably wasn't very clear in my initial post).  That's why 
initially a straight spawn_link to create the worker looked so 
attractive - errors propagate between the gen_server and worker, both 
are cleaned up, and the gen_server's supervisor just restarts the 
gen_server (which is what we want).  That, though, would require us to 
handle the EXIT message from the worker in the gen_server if the latter 
turned on trap_exit (which it seems like it needs to).  It's not a huge 
problem, just seems like something we should be able to avoid.

     The alternative we thought of (that I forgot to mention) is that 
this whole mess seems like it could be neatly avoided if supervisors 
also knew how to shutdown their child - I'm thinking an optional extra 
function in the child_spec that is called before the exit(Child, 
shutdown) call is made.  That would allow the gen_server to do its 
cleanup properly and exit with 'stop'.  There may be a very good (or 
historical or both) reason that that doesn't exist, but it seems to me 
to be the 'right' way to solve the problem...maybe.

Cheers,

Bernard

On 11/05/10 16:58, Mazen Harake wrote:
> Spawn your worker processes in a simple_one_for_one supervisor which is
> under your supervisor. This will propagate the exit to the worker
> processes. Use the gen_server under the first Sup to start a worker
> child in the simple_one_for_one Sup.
>
> In other words; Garrett seems to have gotten it right.
>
> This also eliminates point 3 because the crash will not propagate
> through the gen_server.
>
> I'm assuming from your setup that the gen_server doesn't care if the
> worker crashed or not before it finished, otherwise you might as well
> just trap exits and handle all the exit messages anyway without a
> supervisor.
>
> Hope this makes sense; it is morning here and my coffee cup is still
> full (didn't have a chance to drink it yet :))
>
> Good luck
>
> /Mazen
>
> On 11/05/2010 04:58, Bernard Duggan wrote:
>    
>> Hi list,
>>      This is something of a followup to my previous question about
>> supervision trees.  Basically we have a gen_server that, in the case
>> of a standard app shutdown, needs to do some cleanup.  A standard app
>> shutdown seems to take the form of supervisors sending 'shutdown' exit
>> messages to their children.  Fine so far.  The catch is that in order
>> for the terminate() handler to be invoked on our server, we have to
>> turn on trap_exit in every gen_server that needs to do cleanup.  This
>> seems non-ideal for a few reasons:
>>
>> * Elsewhere in the docs, we're cautioned against using trap_exit
>> except when unavoidable (though I'm happy to accept it if this is one
>> such case).
>>
>> * It means that we don't get automatic propagation of crashes from any
>> worker processes we might spawn.  Instead we have to write a
>> handle_info({'EXIT'...) in every gen_server that might ever link to
>> another process to ensure those crashes are propagated properly.  This
>> seems like it could be solved by instead spawning any worker processes
>> as a child of our supervisor (which is what Garrett suggested we
>> should do anyway) - if that's a good reason to set up things that way,
>> I'm likewise happy to accept it and rearrange our code accordingly.
>>
>> * Most concerning, though, is the possibility of some library call
>> creating a link to a temporary worker process (or any process for that
>> matter) whose crash should propagate through us - in this case we'd
>> still have to have the handle_info({'EXIT'...) setup as a catchall
>> which seems like a fiddly, repetitive bit of code we'd rather avoid if
>> possible.
>>
>> So what's the thinking about this?  Am I missing something obvious?
>> Should I just turn on trap_exit willy-nilly wherever I need shutdown
>> cleanup?  Should I just suck it up and write the 'EXIT' message
>> handlers in all such gen_servers?
>>
>> Cheers,
>>
>> Bernard
>>
>> ________________________________________________________________
>> erlang-questions (at) erlang.org mailing list.
>> See http://www.erlang.org/faq.html
>> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED
>>
>>      
> ---------------------------------------------------
>
> ---------------------------------------------------
>
> WE'VE CHANGED NAMES!
>
> Since January 1st 2010 Erlang Training and Consulting Ltd. has become ERLANG SOLUTIONS LTD.
>
> www.erlang-solutions.com
>
>