[erlang-bugs] Fwd: [erlang-questions] Strange behaviour of exit(kill)

[Robert Virding]

---------- Forwarded message ----------
From: Robert Virding <rvirding@REDACTED>
Date: 6 October 2015 at 18:46
Subject: Re: [erlang-questions] Strange behaviour of exit(kill)
To: zxq9 <zxq9@REDACTED>
Cc: erlang-questions <erlang-questions@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.

Explicitly sending the SIGNAL with exit(Pid, kill) should unconditionally
kill the process as should dying with the reason 'kill' in exit(kill) which
also sends the SIGNAL '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.

My point is that the *same* signal results in different behaviour depending
on how it was sent. That's incocnsistent.

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-bugs/attachments/20151006/8149984c/attachment.htm>