<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2015-10-07 12:27 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>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></div></div></div></blockquote><div>I agree that it is confusing. But note that exit(kill) will not unconditionally terminate the process, so it is apparent that exit/1 and exit/2 are doing different things:<br><br> Erlang/OTP 18 [erts-7.0] [source] [64-bit] [smp:4:4] [async-threads:10] [hipe] [kernel-poll:false]<br><br>Eshell V7.0 (abort with ^G)<br>1> self(). <br><0.34.0><br>2> catch exit(kill).<br>{'EXIT',kill}<br>3> self().<br><0.34.0><br>4> catch exit(self(), kill).<br>** exception exit: killed<br>5> self().<br><0.39.0><br><br>The most confusing thing is that exit(P, Reason) will, in case P is
terminated, propagate exit signals with reason Reason in all cases
except when Reason is kill. In this case the propagated reason is
killed. But as your experiment shows, this is in fact totally
unnecessary since an exit signal with reason kill can be caught anyway...<br><br></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>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.<span class=""></span> <br></div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div><div><span class=""></span></div><span class=""><font color="#888888">Robert<br></font></span><br></div>P.S. I am not even going to mention the terribly inconsistent handling of errors in link/1. <br></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div> <br></div></blockquote><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 class=""><div class="h5"><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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span>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><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><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><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><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><font color="#888888"><br><br></font></span></div><span><font color="#888888"><div>/Håkan<br></div></font></span><div><div><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>
</div></div></blockquote></div><br></div></div>