<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><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 class="">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 class=""><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 class="HOEnZb"><div class="h5"><br>
-Craig<br>
_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">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>