<div dir="ltr"><div><div><div>I still find that extremely inconsistent, there are actually 2 'kill' signals: one that is sent with exit(Pid, kill) and the other which sent when you do exit(kill). So I can trap 'kill' and I can't trap 'kill', great.<br><br></div>I would personally go the other way and say that kill is kill however it is sent. But I agree with you, I'm not holding my breath waiting for it to be fixed.<br><br></div>Robert<br><br></div>P.S. I am not even going to mention the terribly inconsistent handling of errors in link/1.<br><br></div><div class="gmail_extra"><br><div class="gmail_quote">On 7 October 2015 at 00:51, Håkan Huss <span dir="ltr"><<a href="mailto:huss01@gmail.com" target="_blank">huss01@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_extra"><div class="gmail_quote"><span class="">2015-10-07 3:46 GMT+02:00 Robert Virding <span dir="ltr"><<a href="mailto:rvirding@gmail.com" target="_blank">rvirding@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><div>It's all about signals and not messages. Sending a message to a process should *NEVER* by default kill it even if it has the same format as an 'EXIT' message. NEVER!. A signal is converted to a message when it arrives at a process which is trapping exits unless it is the 'kill' which is untrappable and the process always dies.<br><br></div></div></div></div></blockquote></span><div>Yes, but the 'kill' signal is not an exit signal with reason kill. The 'kill' signal can only be sent by calling exit/2 with Reason = kill, which is documented to have the effect that "an untrappable exit signal
is sent to <span>Pid</span> which will unconditionally exit with
exit reason <span>killed</span>." There is no mention of how the exit reason in that exit signal, and since it is not trappable there is no way to observe it. <br> <br></div><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><div></div>Explicitly sending the SIGNAL with exit(Pid, kill) should unconditionally kill the process</div></div></div></blockquote></span><div>Yes. <br><br></div><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div> as should dying with the reason 'kill' in exit(kill) which also sends the SIGNAL 'kill'.</div></div></div></blockquote></span><div>No, this sends an exit signal with reason kill, but that is not the same ass the signal sent using exit(Pid, kill).<br></div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div>In both cases the process receives the SIGNAL 'kill', as shown in my example, but in one case it is trappable and in the other it is untrappable.<br></div></div></div></blockquote></span><div>No, in one case it receives an exit signal with reason kill, in the other case it receives the special untrappable exit signal which causes unconditional termination. <br></div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div></div>My point is that the *same* signal results in different behaviour depending on how it was sent. That's incocnsistent.<span><font color="#888888"><br></font></span></div></div></blockquote></span><div>I agree that it is inconsistent. I would have preferred that the exit(Pid, kill) was a separate function, e.g., kill(Pid) and that exit(Pid, kill) would be handled as any other exit/2 call. But I won't hold my breath in anticipation of that being changed...<span class="HOEnZb"><font color="#888888"><br><br></font></span></div><span class="HOEnZb"><font color="#888888"><div>/Håkan<br></div></font></span><div><div class="h5"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><span><font color="#888888"></font></span></div><span><font color="#888888">Robert<br><br></font></span></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On 6 October 2015 at 18:33, 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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span>On Wednesday 07 October 2015 10:25:38 zxq9 wrote:<br>
<br>
> or maybe it is that {'EXIT', Pid = self(), kill} *is* specifically untrappable by way of matching on self()?<br>
<br>
</span>That was too much to hope for:<br>
<br>
1> P = spawn(fun Loop() -> receive M -> io:format("Got ~p~n", [M]), Loop() end end).<br>
<0.1889.0><br>
2> P ! {'EXIT', P, kill}.<br>
Got {'EXIT',<0.1889.0>,kill}<br>
{'EXIT',<0.1889.0>,kill}<br>
3> P ! {'EXIT', P, blam}.<br>
Got {'EXIT',<0.1889.0>,blam}<br>
{'EXIT',<0.1889.0>,blam}<br>
4> exit(P, kill).<br>
true<br>
5> P ! {'EXIT', P, blam}.<br>
{'EXIT',<0.1889.0>,blam}<br>
<br>
If it *did* turn out that matching {'EXIT', self(), kill} was untrappable I would just say "ah, that makes sense -- now I can understand the mechanism behind this without thinking about VM details". Instead it appears to be a case of mysterious activity underlying a message form that is semantically overloaded. And that stinks.<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><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>
<br></blockquote></div></div></div><br></div></div>
</blockquote></div><br></div>