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

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 <[email protected]> wrote:

> 2015-10-07 3:46 GMT+02:00 Robert Virding <[email protected]>:
>
>> 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 <[email protected]> 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
>>> [email protected]
>>> http://erlang.org/mailman/listinfo/erlang-questions
>>>
>>
>>
>> _______________________________________________
>> erlang-questions mailing list
>> [email protected]
>> http://erlang.org/mailman/listinfo/erlang-questions
>>
>>
>

_______________________________________________
erlang-bugs mailing list
[email protected]
http://erlang.org/mailman/listinfo/erlang-bugs