[erlang-bugs] [erlang-questions] Strange behaviour of exit(kill)
Roland Karlsson
roland.karlsson@REDACTED
Fri Oct 9 03:26:46 CEST 2015
So Robert, tell me who missed it.
What is the difference in behaviour when using exit/1 or exit/2?
And is the difference still there if the process kills itself with exit/2?
/Roland
On 2015-10-09 02:28, Robert Virding wrote:
> 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
> <mailto: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 <mailto:huss01@REDACTED>> wrote:
> > >>
> > >> 2015-10-07 3:46 GMT+02:00 Robert Virding
> <rvirding@REDACTED <mailto: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
> <mailto: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 <mailto:erlang-questions@REDACTED>
> > >> http://erlang.org/mailman/listinfo/erlang-questions
> > >>
> > >>
> > >>
> > >> _______________________________________________
> > >> erlang-questions mailing list
> > >> erlang-questions@REDACTED <mailto:erlang-questions@REDACTED>
> > >> http://erlang.org/mailman/listinfo/erlang-questions
> > >>
> > >>
> > >>
> > >>
> > >>
> > >
> > >>_______________________________________________
> > >>erlang-bugs mailing list
> > >>erlang-bugs@REDACTED <mailto: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 <mailto: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 <tel:%2B39%2002%2032069314> : SKYPE franz.lattanzio
> a-tono.com <http://a-tono.com> : twitter.com/ATonoOfficial
> <http://twitter.com/ATonoOfficial> : facebook.com/ATonoOfficial
> <http://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.
>
>
>
>
> _______________________________________________
> erlang-bugs mailing list
> erlang-bugs@REDACTED
> http://erlang.org/mailman/listinfo/erlang-bugs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-bugs/attachments/20151009/39f39b82/attachment.htm>
More information about the erlang-bugs
mailing list