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

[Soup]

You could even say that OTP relies on this behavior to implement the
brutal_kill termination strategy. If I have a temporary child that is
itself a supervisor that implements brutal_kill, it should absolutely *not*
kill its supervisor, because it is only a temporary child. Not being able
to trap kill signals meant for a process to which a given process is linked
would make this setup impossible.

Hell, what would happen if I called supervisor:terminate_child(Pid, Child)
if the supervisor happened to use the brutal_kill termination strategy?
Bye-bye VM.

On Tue, Oct 6, 2015 at 10:43 PM, Soup <zachary.hueras@REDACTED> wrote:

> Think about this in the context of a supervisor and its children. If the
> child is killed via exit/2, should the supervisor also be killed? And its
> supervisor?
>
> While I agree the behavior is inconsistent, it still seems appropriate to
> me. A kill signal should only kill the process it was meant to kill and any
> non-trapping processes that are linked to it. Without this behavior, it
> would be possible to kill the entire application supervision tree by
> calling exit(Pid, kill) on the lowliest child of an application because no
> process would be able to trap the signal.
>
> ​That being said, you could also go the other way. If I start a process
> that traps exits as part of a supervision tree, then exit(Pid, kill) its
> supervisor​, that process could remain alive even though its supervisor no
> longer exists. A rogue process, if you will.
>
> Personally, I would prefer to deal with the implications of the latter
> than the former, though.
>
>
> On Tue, Oct 6, 2015 at 9:51 PM, zxq9 <zxq9@REDACTED> wrote:
>
>> On Tuesday 06 October 2015 18:46:55 you wrote:
>> > 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.
>>
>> ok
>>
>> > 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.
>>
>> I didn't realize it was propagating the signal in addition to the
>> message. That's even more weird then.
>>
>> -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-questions/attachments/20151006/6c50208d/attachment.htm>