<div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">You could even say that OTP relies on this behavior to implement the brutal_kill termination strategy. If I have a temporary child that is itself a supervisor that implements brutal_kill, it should absolutely *not* kill its supervisor, because it is only a temporary child. Not being able to trap kill signals meant for a process to which a given process is linked would make this setup impossible.<br><br>Hell, what would happen if I called supervisor:terminate_child(Pid, Child) if the supervisor happened to use the brutal_kill termination strategy? Bye-bye VM.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Oct 6, 2015 at 10:43 PM, Soup <span dir="ltr"><<a href="mailto:zachary.hueras@gmail.com" target="_blank">zachary.hueras@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Think about this in the context of a supervisor and its children. If the child is killed via exit/2, should the supervisor also be killed? And its supervisor?<br><br>While I agree the behavior is inconsistent, it still seems appropriate to me. A kill signal should only kill the process it was meant to kill and any non-trapping processes that are linked to it. Without this behavior, it would be possible to kill the entire application supervision tree by calling exit(Pid, kill) on the lowliest child of an application because no process would be able to trap the signal.<br></div><div class="gmail_extra"><br><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">​That being said, you could also go the other way. If I start a process that traps exits as part of a supervision tree, then exit(Pid, kill) its supervisor​, that process could remain alive even though its supervisor no longer exists. A rogue process, if you will.<br><br>Personally, I would prefer to deal with the implications of the latter than the former, though.</div><div><div class="h5"><br><br><div class="gmail_quote">On Tue, Oct 6, 2015 at 9:51 PM, zxq9 <span dir="ltr"><<a href="mailto:zxq9@zxq9.com" target="_blank">zxq9@zxq9.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On Tuesday 06 October 2015 18:46:55 you wrote:<br>
> It's all about signals and not messages. Sending a message to a process<br>
> should *NEVER* by default kill it even if it has the same format as an<br>
> 'EXIT' message. NEVER!. A signal is converted to a message when it arrives<br>
> at a process which is trapping exits unless it is the 'kill' which is<br>
> untrappable and the process always dies.<br>
<br>
</span>ok<br>
<span><br>
> Explicitly sending the SIGNAL with exit(Pid, kill) should unconditionally<br>
> kill the process as should dying with the reason 'kill' in exit(kill) which<br>
> also sends the SIGNAL 'kill'. In both cases the process receives the SIGNAL<br>
> 'kill', as shown in my example, but in one case it is trappable and in the<br>
> other it is untrappable.<br>
<br>
</span>I didn't realize it was propagating the signal in addition to the message. That's even more weird then.<br>
<div><div><br>
-Craig<br>
_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</div></div></blockquote></div><br></div></div></div></div>
</blockquote></div><br></div>