<div dir="ltr"><div>I think to realise here is that exit(kill) sends a 'kill' SIGNAL not a message. It is the fact that the shell process is trapping exits which means that the signal is converted to a message when it arrives at the shell process. Sending a message, irrespective of it format, will never kill a process.<br><br></div><div>My point was just that if the same 'kill' signal is sent by exit/1 or exit/2 it will result in different behaviour in the process which receives the signal. So it is not just the signal itself which causes the behaviour but how it was sent. I find this inconsistent. Should a word on the screen look different whether I write with the left hand or the right hand?<br><br></div>Robert<br><br></div><div class="gmail_extra"><br><div class="gmail_quote">On 8 October 2015 at 05:57, Francesco Lattanzio <span dir="ltr"><<a href="mailto:francesco.lattanzio@a-tono.com" target="_blank">francesco.lattanzio@a-tono.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">But:<br>
<br>
1> Pid = spawn_link(fun() -> exit(kill) end).<br>
** exception exit: killed<br>
2> f().<br>
ok<br>
3> process_flag(trap_exit, true).<br>
false<br>
4> Pid = spawn_link(fun() -> exit(kill) end).<br>
<0.40.0><br>
5> flush().<br>
Shell got {'EXIT',<0.40.0>,kill}<br>
ok<br>
<br>
Regards.<br>
<div><div class="h5"><br>
On Thu, Oct 08, 2015 at 02:37:19PM +0200, Loďc Hoguin wrote:<br>
> On 10/07/2015 02:27 PM, Francesco Lattanzio wrote:<br>
> >I always thought that when a process dies because it was sent a 'kill'<br>
> >message it would broadcast to the linked processes a 'killed' EXIT<br>
> >message (see Concurrent Programming in Erlang - Part I, D.3 Exit<br>
> >signals, p. 193 ).<br>
> >However for some reason recent implementations of the VM broadcasts a<br>
> >'kill' EXIT message (I could only test it on Erlang VMs as old as<br>
> >R13B04).<br>
><br>
> 1> Pid = spawn_link(fun() -> receive after infinity -> ok end end).<br>
> <0.36.0><br>
> 2> exit(Pid, kill).<br>
> ** exception exit: killed<br>
> 3> f().<br>
> ok<br>
> 4> Pid = spawn_link(fun() -> receive after infinity -> ok end end).<br>
> <0.41.0><br>
> 5> process_flag(trap_exit, true).<br>
> false<br>
> 6> exit(Pid, kill).<br>
> true<br>
> 7> flush().<br>
> Shell got {'EXIT',<0.41.0>,killed}<br>
> ok<br>
><br>
> Cheers,<br>
><br>
> >I'm not asking to revert this behaviour (I bet such a change would<br>
> >impact a lot of code), however it would be nice to know why it was<br>
> >chosen a two-semantics kill message instead of more obvious two<br>
> >one-semantic kill and killed message (if someone knows).<br>
> ><br>
> >On Wed, Oct 07, 2015 at 03:27:24AM -0700, Robert Virding wrote:<br>
> >>I still find that extremely inconsistent, there are actually 2 'kill' signals: one that is sent with exit(Pid, kill) and the other<br>
> >>which sent when you do exit(kill). So I can trap 'kill' and I can't trap 'kill', great.<br>
> >><br>
> >>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<br>
> >>waiting for it to be fixed.<br>
> >><br>
> >>Robert<br>
> >><br>
> >>P.S. I am not even going to mention the terribly inconsistent handling of errors in link/1.<br>
> >><br>
> >><br>
</div></div><span class="">> >>On 7 October 2015 at 00:51, Hĺkan Huss <<a href="mailto:huss01@gmail.com">huss01@gmail.com</a>> wrote:<br>
> >><br>
> >> 2015-10-07 3:46 GMT+02:00 Robert Virding <<a href="mailto:rvirding@gmail.com">rvirding@gmail.com</a>>:<br>
> >><br>
> >> It's all about signals and not messages. Sending a message to a process should *NEVER* by default kill it even if it has<br>
> >> the same format as an 'EXIT' message. NEVER!. A signal is converted to a message when it arrives at a process which is<br>
> >> trapping exits unless it is the 'kill' which is untrappable and the process always dies.<br>
> >><br>
> >><br>
> >> 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<br>
> >> Reason = kill, which is documented to have the effect that "an untrappable exit signal is sent to Pid which will<br>
> >> unconditionally exit with exit reason killed." There is no mention of how the exit reason in that exit signal, and since it is<br>
> >> not trappable there is no way to observe it.<br>
> >><br>
> >><br>
> >> Explicitly sending the SIGNAL with exit(Pid, kill) should unconditionally kill the process<br>
> >><br>
> >> Yes.<br>
> >><br>
> >><br>
> >> as should dying with the reason 'kill' in exit(kill) which also sends the SIGNAL 'kill'.<br>
> >><br>
> >> No, this sends an exit signal with reason kill, but that is not the same ass the signal sent using exit(Pid, kill).<br>
> >><br>
> >><br>
> >> In both cases the process receives the SIGNAL 'kill', as shown in my example, but in one case it is trappable and in the<br>
> >> other it is untrappable.<br>
> >><br>
> >> No, in one case it receives an exit signal with reason kill, in the other case it receives the special untrappable exit signal<br>
> >> which causes unconditional termination.<br>
> >><br>
> >><br>
> >> My point is that the *same* signal results in different behaviour depending on how it was sent. That's incocnsistent.<br>
> >><br>
> >> I agree that it is inconsistent. I would have preferred that the exit(Pid, kill) was a separate function, e.g., kill(Pid) and<br>
> >> 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<br>
> >> changed...<br>
> >><br>
</span>> >> /Hĺkan<br>
<div><div class="h5">> >><br>
> >><br>
> >> Robert<br>
> >><br>
> >><br>
> >> On 6 October 2015 at 18:33, zxq9 <<a href="mailto:zxq9@zxq9.com">zxq9@zxq9.com</a>> wrote:<br>
> >><br>
> >> 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>
> >> 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<br>
> >> I can understand the mechanism behind this without thinking about VM details". Instead it appears to be a case of<br>
> >> mysterious activity underlying a message form that is semantically overloaded. And that stinks.<br>
> >><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>
> >><br>
> >><br>
> >><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>
> >><br>
> >><br>
> >><br>
> >><br>
> >><br>
> ><br>
> >>_______________________________________________<br>
> >>erlang-bugs mailing list<br>
> >><a href="mailto:erlang-bugs@erlang.org">erlang-bugs@erlang.org</a><br>
> >><a href="http://erlang.org/mailman/listinfo/erlang-bugs" rel="noreferrer" target="_blank">http://erlang.org/mailman/listinfo/erlang-bugs</a><br>
> ><br>
> ><br>
><br>
> --<br>
</div></div>> Loďc Hoguin<br>
<span class="im HOEnZb">> <a href="http://ninenines.eu" rel="noreferrer" target="_blank">http://ninenines.eu</a><br>
> Author of The Erlanger Playbook,<br>
> A book about software development using Erlang<br>
</span><span class="im HOEnZb">> _______________________________________________<br>
> erlang-bugs mailing list<br>
> <a href="mailto:erlang-bugs@erlang.org">erlang-bugs@erlang.org</a><br>
> <a href="http://erlang.org/mailman/listinfo/erlang-bugs" rel="noreferrer" target="_blank">http://erlang.org/mailman/listinfo/erlang-bugs</a><br>
<br>
--<br>
</span><div class="HOEnZb"><div class="h5">FRANCESCO LATTANZIO : SYSTEM & SOFTWARE<br>
A-TONO TECHNOLOGY : VIA DEL CHIESINO, 10 - 56025 PONTEDERA (PI) : T <a href="tel:%2B39%2002%2032069314" value="+390232069314">+39 02 32069314</a> : SKYPE franz.lattanzio<br>
<a href="http://a-tono.com" rel="noreferrer" target="_blank">a-tono.com</a> : <a href="http://twitter.com/ATonoOfficial" rel="noreferrer" target="_blank">twitter.com/ATonoOfficial</a> : <a href="http://facebook.com/ATonoOfficial" rel="noreferrer" target="_blank">facebook.com/ATonoOfficial</a><br>
<br>
Information in this email is confidential and may be privileged. It is intended for the addresses only.<br>
If you have received it in error, please notify the sender immediately and delete it from your system.<br>
You should not otherwise copy it, retransmit it or use or disclose its content to anyone. Thank you for your co-operation.<br>
</div></div></blockquote></div><br></div>