[erlang-patches] Supervisor improvements

[Siri Hansen]

2011/9/14 Henrik Nord <henrik@REDACTED>

> On 09/08/2011 10:57 AM, Christopher Faulet wrote:
>
>> git fetch git://github.com/capflam/otp.**git<http://github.com/capflam/otp.git>supervisor_shutdown_infinity
>>
> I have included this branch in 'pu'
>
> Thank you for the contribution.
>
> No news about the other one as of yet
>
> Thank you for the contribution!
>
> --
> /Henrik Nord Erlang/OTP
>
>
> ______________________________**_________________
> erlang-patches mailing list
> erlang-patches@REDACTED
> http://erlang.org/mailman/**listinfo/erlang-patches<http://erlang.org/mailman/listinfo/erlang-patches>
>

Hi again Christopher - thanks for the information!!

I have discussed the simple_one_for_one_shutdown problem with my colleagues,
and finally we came to the same conclusion as you did :) The current
behavior is definitely not acceptable so we decided to take in you patch. If
you don't mind I would however like you to do some minor adjustments first:

1) I think it would be good to document the differences in how shutdown is
handled for simple_one_for_one supervisors compared to other supervisors.
I.e. that there is no defined shutdown order, and that the workers will
terminate "in parallel".

2) If the shutdown strategy for the dynamic children is a timer, and the
timer expires - then it looks like there will be one error report printed
per worker that is not yet terminated (please correct me if I'm wrong). I
believe that this could be quite heavy if there are many workers left. I
would suggest to print only one error report in this situation - either
listing all pids or just say how many processes we are talking about.


Also, as Henrik writes, your supervisor_shutdown_infinity patch is already
included in pu. Before finally including it in our development branch, I
would also like you to add some more information to the documentation (a
warning?) - about using this feature with care, and if you need to use it
then implement the worker in a safe way so the cleanup procedure can not
hang... since this can actually cause the termination of the complete
supervisor tree to hang.

Thanks!
/siri
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-patches/attachments/20110914/52e3640d/attachment.htm>