Re: Re: [erlang-questions] Erlang's process not killed by exit signalreasoned by "kill"

[Yan Yan]

Thanks, Richard

In fact, I had a very similiar thought with yours as I found b killed when b is not a system process but b not killed when b is a system process.

However, even if exit(kill) acts the same as exit(self(), kill) does, there seems to be problems left. For example, if, in this setup, c does want ALL linked processes to be killed when c itself exits abnormally, we will want a simple code in c() just like exit(kill). In this way, we want all processes linked to c will be killed because of c's exit, even if there were any system processes among c's linked processes. Currently, if we write exit(kill) or exit(self(), kill) in c(), only c and c's linked non-system processes will be killed, but all system processed linked will survive, which is not correct.

So far, there seems to be no other ways to let it happen correctly except:

Code:

c(......) ->
blabla...

%% P1, P2, ..., Pn are linked SYSTEM processes
exit(P1, kill),
exit(P2, kill),
...
exit(Pn, kill),

%%Here c is still alive, and we want c and its linked non-system processes also killed, so...
exit(kill). %% or exit(self(), kill), or exit(anything)..

End code.

However, it still demands that programmers know ahead of time how many and which system processes are linked to c, which is not a good design pattern.

Sincerely,

Yan Yan




Yan Yan
2009-10-24



From: Richard Carlsson
Time:  2009-10-24 21:05:05
To: Yan Yan
Fw: erlang-questions; erlang-bugs; Bj鰎n_Gustavsson
Subject: Re: [erlang-questions] Erlang's process not killed by exit signalreasoned by "kill"

Yan Yan wrote:
> (2)On Page 169,
(Page 161 in my copy of the book.)
> Quote:
> 
> 8> edemo1:start(true, {die,kill}).  Process b received
> {'EXIT',<0.73.0>,kill} process b (<0.72.0>) is alive process c
> (<0.73.0>) is dead ok
> 
> End quote.
> 
> Here a and b are both system processes, while c is not. When c exits
> with the reason "kill" (not "killed"), it sends exit signal to b with
> the reason "kill". Therefore b should be killed and dead, but b is
> still alive here!
> 
> (I had thought it was only a small typo in the book. But then I
> tested by myself and got the same result: b received the exit signal
> with the reason "kill" and b was not killed but alive.)
> 
> Why is the system process b not killed by the exit signal with the
> reason "kill"?
Interesting. There seems to be a difference in behaviour (probably
not intentional) between `exit(kill)' and `exit(self(),kill)'.
A summary of the setup: we have three processes, linked in a chain.
'a' is always trapping, 'b' may or may not be trapping, and 'c' is
the one who dies by calling exit(Reason).
  1. When 'b' is not trapping, and 'c' does exit(kill), we see a
     report from 'a' that 'b' died with reason 'killed'.
  2. When 'b' is trapping, and 'c' does exit(kill), 'b' survives
     and reports that it sees the exit reason 'kill' from 'c'
     (not 'killed').
The question is: in case 2, why didn't 'b' die, when it apparently
got a 'kill' message. This should be untrappable, which is why it is
changed to 'killed' when it is propagated. But it was 'c' who died,
so why wasn't the atom changed to 'killed'?
If we change `exit(kill)' to `exit(self(),kill)' in 'c', we get the
effect we expected: 'b' survives and reports that it sees 'killed'
as the exit reason from 'c'.
Then, a new question is why 'a' saw 'killed' in case 1 when 'b' is
non-trapping. If 'c' dies in the same way in both, then doesn't
'b' get the same signal from 'c'? Apparently, it does, but since
'b' is not trapping, it doesn't matter what the atom is as long
as it is something else than 'normal'. So 'b' dies due to an
incoming 'kill', and this is then propagated as 'killed'.
It seems that when a process does exit(kill) on itself, it causes
a different outgoing signal than if it does exit(self(),kill).
The former is not untrappable even though it has the reason 'kill',
but if that in its turn causes another process to die, the atom
will _then_ be rewritten to 'killed'.
To me, it seems that this should be fixed so that exit(kill), even
if it's an unusual case, should be propagated as 'killed'.
     /Richard