Hi Vance,<div><br></div><div>a while back (I think R13B), there was a change in stdlib (from the release note):</div><div><br></div><div>"When a process started with proc_lib, gen_server, or gen_fsm exits with reason {shutdown,Term}, a crash report will no longer be generated (to allow a clean shutdown, but still provide additional information to process that are linked to the terminating process)."</div>

<div><br></div><div>I think - what causes your particular problem in radius is that supervisor is not adapted to this change. I.e. even though there will be no error- or crash report from the child process (gen_fsm) itself, there will still be a supervisor report.</div>

<div><br></div><div>We find it fair to correct this! However, this change will not be fully backwards compatible because removing the supervisor report is not enough - we must also remove the supervisor's attempt at restarting the child (depening on the child's restart type). This means that we can not do this in a patch release - we must wait for R15.</div>

<div><br></div><div><br></div><div>When it comes to {normal,Info} we have decided not to implement that since it is not obvious how it should work (if it should be equivalent to normal (which has a special meaning in the language) or as shutdown (which really only has a special meaning in OTP/supervisor/proc_lib)).</div>
<div><br></div><div><br></div><div>I hope this is an ok solution for you? I will do the correction for R15.</div><div><br></div><div>Regards</div><div>/siri</div><div><br></div><div><br></div><div><br></div><div><br><br><div class="gmail_quote">
2011/4/13 Vance Shipley <span dir="ltr"><<a href="mailto:vances@motivity.ca" target="_blank">vances@motivity.ca</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Siri et. al.,<br>
<br>
Thank you, I'm glad there is agreement that the functionality is desired.<br>
<br>
In a similiar vein I'd like to see an enhancement to allow passing<br>
information back in the exit message of a child.  Currently a child's<br>
init/1 function may return {ok,Child} or {ok,Child,Info} and<br>
supervisor:start_child/2 returns the same.  I'd like to see the inverse<br>
where the child may exit with either 'shutdown' or {shutdown, Info},<br>
in response to a shutdown request from it's supervisor, and 'normal'<br>
or {normal, Info} for a normal exit.<br>
<br>
The child may exit with any value now of course however if the exit<br>
value isn't expected the supervisor restart strategy and SASL error<br>
logging will not work as desired.<br>
<br>
You may look to my radierl(*) project for an example of a practical<br>
application of this functionality.  In this stack application the<br>
radius_server module implements a gen_server which will dynamically<br>
start a new gen_fsm process, under supervision, to service requests.<br>
It keeps the gen_fsm's pid in state stored in a gb_tree() with the<br>
client's info as the key.  In this way client requests can be quickly<br>
looked up and forwarded to the gen_fsm.  When the gen_fsm terminates<br>
the gen_server needs to reap the state.<br>
<br>
I implemented a clause in radius_server to efficiently do this:<br>
<br>
        handle_info({'EXIT', _Pid, {shutdown, Key}},<br>
                #state{handlers = Handlers} = State) -><br>
            NewHandlers = gb_trees:delete(Key, Handlers),<br>
            NewState = State#state{handlers = NewHandlers},<br>
            {noreply, NewState};<br>
<br>
However I can't use this because SASL reports are generated for normal<br>
terminations.  Instead I have to handle the normal expected termination<br>
case in the same way as the unexpected case (i.e. inefficiently):<br>
<br>
        handle_info({'EXIT', Fsm, _Reason},<br>
              #state{handlers = Handlers} = State) -><br>
           Fdel = fun(_F, {Key, Pid, _Iter}) when Pid == Fsm -><br>
                    Key;<br>
                 (F, {_Key, _Val, Iter}) -><br>
                    F(F, gb_trees:next(Iter));<br>
                 (_F, none) -><br>
                    none<br>
           end,<br>
           Iter = gb_trees:iterator(Handlers),<br>
           case Fdel(Fdel, gb_trees:next(Iter)) of<br>
              none -><br>
                 {noreply, State};<br>
              Key -><br>
                 NewHandlers = gb_trees:delete(Key, Handlers),<br>
                 NewState = State#state{handlers = NewHandlers},<br>
                 {noreply, NewState}<br>
           end.<br>
<br>
I would be willing to implement a patch if the team agrees with the<br>
approach.<br>
<div><br>
        -Vance<br>
<br>
(*)  <a href="http://github.com/vances/radierl" target="_blank">http://github.com/vances/radierl</a><br>
</div>     <a href="http://motivity.ca/radius" target="_blank">http://motivity.ca/radius</a><br>
<div><div></div><div><br>
On Wed, Apr 06, 2011 at 10:40:56AM +0200, Siri Hansen wrote:<br>
}  We have now discussed this matter and decided that instead of adding a new<br>
}  terminate/1 function we will add a clause to terminate_child/2 and allow the<br>
}  child to be pointed out by Pid instead of Id.<br>
}<br>
}  The correction will be included in R14B03.<br>
}<br>
}  Thank you for the contribution!<br>
}<br>
}  Best regards<br>
}  /siri<br>
</div></div></blockquote></div><br></div>