[erlang-questions] terminate supervisor from it's child process

block.rxckin.beats@REDACTED block.rxckin.beats@REDACTED
Fri Feb 15 09:39:15 CET 2019


I solved this problem by using linking workers.

          s_1_f_1
udp_sup -----  udp_worker_sup - udp_worker
                   |- dtls_worker_sup - dtls_worker
                   |- srtp_worker_sup - srtp_worker
                   |- stun_worker_sup - stun_worker

start udp_worker for single UDP socket,
and start dtls/srtp/stun workers in init() of udp_worker,
and udp_worker link with ever other workers.
if any worker terminates, ever other worker handling
same UDP socket will terminate.

no need to supervisor for single UDP socket
and terminate supervisor for socket closing.

thanks

Jxck


2019年2月15日(金) 8:23 <block.rxckin.beats@REDACTED>:

> in that case, is child of udp_sup "permanent" or "temporary" ?
>
> if temporary, udp_sup seems ignore udp_worker's terminate, and proto_sup
> still alive.
>
> if permanent, udp_sup try to restart child which I don't expected. and if
> *failed to restart* udp_sup will terminate.
>
> so, you mean, "fail to restart permanent  udp_worker(which unexpected)
> will terminate udp_sup eventually in one_for_all" is correct way to
> terminate supervisor from its child?
>
> thanks
> Jxck
>
> 2019/02/15 2:09、Vance Shipley <vances@REDACTED>のメール:
>
> > On Thu, Feb 14, 2019 at 2:40 PM block.rxckin.beats@REDACTED
> > <block.rxckin.beats@REDACTED> wrote:
> >>> No, I meant:
> >>>    udp_sup
> >>>         -> udp_worker
> >>>         -> proto_sup
> >>>              -> dtls_woker
> >>>              -> stun_worker
> >>>              -> srtp_worker
> >>
> >> in that case,
> >> udp_worker can terminate proto_sup
> >> but who terminate udp_sup ?
> >
> > No, udp_sup terminates proto_sup. Use a one_for_all strategy on
> > udp_sup. When udp_worker exits all the others are terminated by the
> > supervisors.
> >
> > --
> >     -Vance
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20190215/550c46e4/attachment.htm>


More information about the erlang-questions mailing list