[erlang-questions] [erlang-bugs] Strange behaviour of exit(kill)
Robert Virding
rvirding@REDACTED
Fri Oct 9 02:28:07 CEST 2015
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.
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?
Robert
On 8 October 2015 at 05:57, Francesco Lattanzio <
francesco.lattanzio@REDACTED> wrote:
> But:
>
> 1> Pid = spawn_link(fun() -> exit(kill) end).
> ** exception exit: killed
> 2> f().
> ok
> 3> process_flag(trap_exit, true).
> false
> 4> Pid = spawn_link(fun() -> exit(kill) end).
> <0.40.0>
> 5> flush().
> Shell got {'EXIT',<0.40.0>,kill}
> ok
>
> Regards.
>
> On Thu, Oct 08, 2015 at 02:37:19PM +0200, Loďc Hoguin wrote:
> > On 10/07/2015 02:27 PM, Francesco Lattanzio wrote:
> > >I always thought that when a process dies because it was sent a 'kill'
> > >message it would broadcast to the linked processes a 'killed' EXIT
> > >message (see Concurrent Programming in Erlang - Part I, D.3 Exit
> > >signals, p. 193 ).
> > >However for some reason recent implementations of the VM broadcasts a
> > >'kill' EXIT message (I could only test it on Erlang VMs as old as
> > >R13B04).
> >
> > 1> Pid = spawn_link(fun() -> receive after infinity -> ok end end).
> > <0.36.0>
> > 2> exit(Pid, kill).
> > ** exception exit: killed
> > 3> f().
> > ok
> > 4> Pid = spawn_link(fun() -> receive after infinity -> ok end end).
> > <0.41.0>
> > 5> process_flag(trap_exit, true).
> > false
> > 6> exit(Pid, kill).
> > true
> > 7> flush().
> > Shell got {'EXIT',<0.41.0>,killed}
> > ok
> >
> > Cheers,
> >
> > >I'm not asking to revert this behaviour (I bet such a change would
> > >impact a lot of code), however it would be nice to know why it was
> > >chosen a two-semantics kill message instead of more obvious two
> > >one-semantic kill and killed message (if someone knows).
> > >
> > >On Wed, Oct 07, 2015 at 03:27:24AM -0700, Robert Virding wrote:
> > >>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.
> > >>
> > >>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.
> > >>
> > >>Robert
> > >>
> > >>P.S. I am not even going to mention the terribly inconsistent handling
> of errors in link/1.
> > >>
> > >>
> > >>On 7 October 2015 at 00:51, Hĺkan Huss <huss01@REDACTED> wrote:
> > >>
> > >> 2015-10-07 3:46 GMT+02:00 Robert Virding <rvirding@REDACTED>:
> > >>
> > >> 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.
> > >>
> > >>
> > >> 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 Pid which will
> > >> unconditionally exit with exit reason killed." 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.
> > >>
> > >>
> > >> Explicitly sending the SIGNAL with exit(Pid, kill) should
> unconditionally kill the process
> > >>
> > >> Yes.
> > >>
> > >>
> > >> as should dying with the reason 'kill' in exit(kill) which
> also sends the SIGNAL 'kill'.
> > >>
> > >> No, this sends an exit signal with reason kill, but that is not
> the same ass the signal sent using exit(Pid, kill).
> > >>
> > >>
> > >> 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.
> > >>
> > >> 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.
> > >>
> > >>
> > >> My point is that the *same* signal results in different
> behaviour depending on how it was sent. That's incocnsistent.
> > >>
> > >> 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...
> > >>
> > >> /Hĺkan
> > >>
> > >>
> > >> Robert
> > >>
> > >>
> > >> On 6 October 2015 at 18:33, zxq9 <zxq9@REDACTED> wrote:
> > >>
> > >> On Wednesday 07 October 2015 10:25:38 zxq9 wrote:
> > >>
> > >> > or maybe it is that {'EXIT', Pid = self(), kill} *is*
> specifically untrappable by way of matching on self()?
> > >>
> > >> That was too much to hope for:
> > >>
> > >> 1> P = spawn(fun Loop() -> receive M -> io:format("Got
> ~p~n", [M]), Loop() end end).
> > >> <0.1889.0>
> > >> 2> P ! {'EXIT', P, kill}.
> > >> Got {'EXIT',<0.1889.0>,kill}
> > >> {'EXIT',<0.1889.0>,kill}
> > >> 3> P ! {'EXIT', P, blam}.
> > >> Got {'EXIT',<0.1889.0>,blam}
> > >> {'EXIT',<0.1889.0>,blam}
> > >> 4> exit(P, kill).
> > >> true
> > >> 5> P ! {'EXIT', P, blam}.
> > >> {'EXIT',<0.1889.0>,blam}
> > >>
> > >> 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.
> > >>
> > >> -Craig
> > >> _______________________________________________
> > >> erlang-questions mailing list
> > >> erlang-questions@REDACTED
> > >> http://erlang.org/mailman/listinfo/erlang-questions
> > >>
> > >>
> > >>
> > >> _______________________________________________
> > >> erlang-questions mailing list
> > >> erlang-questions@REDACTED
> > >> http://erlang.org/mailman/listinfo/erlang-questions
> > >>
> > >>
> > >>
> > >>
> > >>
> > >
> > >>_______________________________________________
> > >>erlang-bugs mailing list
> > >>erlang-bugs@REDACTED
> > >>http://erlang.org/mailman/listinfo/erlang-bugs
> > >
> > >
> >
> > --
> > Loďc Hoguin
> > http://ninenines.eu
> > Author of The Erlanger Playbook,
> > A book about software development using Erlang
> > _______________________________________________
> > erlang-bugs mailing list
> > erlang-bugs@REDACTED
> > http://erlang.org/mailman/listinfo/erlang-bugs
>
> --
> FRANCESCO LATTANZIO : SYSTEM & SOFTWARE
> A-TONO TECHNOLOGY : VIA DEL CHIESINO, 10 - 56025 PONTEDERA (PI) : T +39
> 02 32069314 : SKYPE franz.lattanzio
> a-tono.com : twitter.com/ATonoOfficial : facebook.com/ATonoOfficial
>
> Information in this email is confidential and may be privileged. It is
> intended for the addresses only.
> If you have received it in error, please notify the sender immediately and
> delete it from your system.
> You should not otherwise copy it, retransmit it or use or disclose its
> content to anyone. Thank you for your co-operation.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20151008/191d0ada/attachment.htm>
More information about the erlang-questions
mailing list