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

[Soup]

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/1093668d/attachment.htm>