<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
So Robert, tell me who missed it.<br>
What is the difference in behaviour when using exit/1 or exit/2?<br>
And is the difference still there if the process kills itself with
exit/2?<br>
<br>
/Roland<br>
<br>
<br>
<br>
<br>
<div class="moz-cite-prefix">On 2015-10-09 02:28, Robert Virding
wrote:<br>
</div>
<blockquote
cite="mid:CAH_GQaOjucO3pKsh2BjvsQbaAmFaMn0UY-0a9+4ByyXtafzYEw@mail.gmail.com"
type="cite">
<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 moz-do-not-send="true"
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 moz-do-not-send="true"
href="mailto:huss01@gmail.com">huss01@gmail.com</a>>
wrote:<br>
> >><br>
> >> 2015-10-07 3:46 GMT+02:00 Robert Virding
<<a moz-do-not-send="true"
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 moz-do-not-send="true"
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 moz-do-not-send="true"
href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
> >> <a moz-do-not-send="true"
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 moz-do-not-send="true"
href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
> >> <a moz-do-not-send="true"
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 moz-do-not-send="true"
href="mailto:erlang-bugs@erlang.org">erlang-bugs@erlang.org</a><br>
> >><a moz-do-not-send="true"
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 moz-do-not-send="true"
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 moz-do-not-send="true"
href="mailto:erlang-bugs@erlang.org">erlang-bugs@erlang.org</a><br>
> <a moz-do-not-send="true"
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 moz-do-not-send="true"
href="tel:%2B39%2002%2032069314" value="+390232069314">+39
02 32069314</a> : SKYPE franz.lattanzio<br>
<a moz-do-not-send="true" href="http://a-tono.com"
rel="noreferrer" target="_blank">a-tono.com</a> : <a
moz-do-not-send="true"
href="http://twitter.com/ATonoOfficial"
rel="noreferrer" target="_blank">twitter.com/ATonoOfficial</a>
: <a moz-do-not-send="true"
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>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
erlang-bugs mailing list
<a class="moz-txt-link-abbreviated" href="mailto:erlang-bugs@erlang.org">erlang-bugs@erlang.org</a>
<a class="moz-txt-link-freetext" href="http://erlang.org/mailman/listinfo/erlang-bugs">http://erlang.org/mailman/listinfo/erlang-bugs</a>
</pre>
</blockquote>
<br>
</body>
</html>