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

[Håkan Huss]

2015-10-07 12:27 GMT+02:00 Robert Virding <rvirding@REDACTED>:

> 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 agree that it is confusing. But note that exit(kill) will not
unconditionally terminate the process, so it is apparent that exit/1 and
exit/2 are doing different things:

 Erlang/OTP 18 [erts-7.0] [source] [64-bit] [smp:4:4] [async-threads:10]
[hipe] [kernel-poll:false]

Eshell V7.0  (abort with ^G)
1> self().
<0.34.0>
2> catch exit(kill).
{'EXIT',kill}
3> self().
<0.34.0>
4> catch exit(self(), kill).
** exception exit: killed
5> self().
<0.39.0>

The most confusing thing is that exit(P, Reason) will, in case P is
terminated, propagate exit signals with reason Reason in all cases except
when Reason is kill. In this case the propagated reason is killed. But as
your experiment shows, this is in fact totally unnecessary since an exit
signal with reason kill can be caught anyway...

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
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20151007/4bcb1e3c/attachment.htm>