Erlang's process not killed by exit signal reasoned by "kill"

[Yan Yan-2]

I am extremely interested in Erlang. However, there is a quite confusing question in Joe's textbook "Programming Erlang, Software for a Concurrent World". I cannot figure it out so I am now sending you an email to talk about it.

(1)On Page 163,

Quote

If the reason is given as kill, then an untrappable exit signal will be sent.
An untrappable exit signal will always kill the process it is sent to, even
if it is a system process.

End quote

(2)On Page 169,

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"?

P.S. interesting is that if the code exit(kill) in process c is changed to exit(B, kill), b is killed by that signal, which is not conflict with quote on Page 163. I have also tested that both exit(kill) and exit(B, kill) send the same exit signal ({'EXIT', c's Pid, kill}) to B.

Thanks a lot. It will be my honor if anyone can give me a reply and I am looking forward to it.

Sincerely,

Yan Yan

[Yan Yan-2]

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

[Yan Yan-2]

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

[Robert Virding]

I just want to clear up one little point: there is in fact only one type of
process, all processes behave in the same way with respect to dying and exit
signals. So what Joe calls "system processes" are just processes started by
the system, nothing more.

That exit(kill) and exit(Self, kill) behave differently is *exactly* as it
should be, they are *defined* to behave differently. exit/2 will *always*
send an exit signal to the process even if the process itself! Its behaviour
is consistent. When sending to itself the process should behave as if the
exit signal came from "outside" the itself. This means that if you are
trapping exits you should also trap the exits from exit/2 to yourself.

Oth an exit/1 works "internally". It should behave in the same way as
erlang:error/1. In fact originally they were the same and there was only
exit/1. Internal errors also looked the same as exit/1. Things started to
drift apart when internal errors got stack traces. Now stack traces are a
Good Thing but it meant that the behaviour of errors and exit/1 diverged.
Unfortunately, instead of fixing exit/1, which would have been the most
sensible thing to do, the split was made permanent by adding error/1.

So exit/1 and error/1 should behave in the same way, which is different to
exit/2.

'kill' is a little special as we felt we needed something which wasn't
trappable but at the same time we realised that if it spread in the same way
as other exit signals then it would be uncontrollable. This is why it was
decided that when a process received an exit 'kill' signal it should always
unconditionally die but only resignal 'killed' to its linked processes.
Whether doing exit(kill) should send a real exit 'kill' signal or only a
'killed' signal is an interesting question which I can't remember now what
we decided. If it sends an exit 'kill' signal then it should behave as a
real 'kill' signal and be non-trappable.

This definitely something for the Erlang Rationale!

Robert

2009/10/24 Yan Yan <yan.beijing.china@...>

> 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
>

[Robert Virding]

2009/10/24 Richard Carlsson <carlsson.richard@...>

> Robert Virding wrote:
>
>> That exit(kill) and exit(Self, kill) behave differently is *exactly* as it
>> should be, they are *defined* to behave differently.
>>  [...]
>>
>> Whether doing exit(kill) should send a real exit 'kill' signal or only a
>> 'killed' signal is an interesting question which I can't remember now what
>> we decided. If it sends an exit 'kill' signal then
>> it should behave as a real 'kill' signal and be non-trappable.
>>
>
> The problem now was that it didn't do either: it sends off a signal
> that says 'kill', but which isn't a real non-trappable kill signal.
> So the behaviour is different where it shouldn't be.
>

Yes. Unfortunately, to my knowledge discussion of this has never come
before.

Robert

P.S. This type of thing is a good reason to have a proper language spec.

[Joe Armstrong-2]

On Sat, Oct 24, 2009 at 9:10 PM, Robert Virding <rvirding@...> wrote:
> I just want to clear up one little point: there is in fact only one type of
> process, all processes behave in the same way with respect to dying and exit
> signals. So what Joe calls "system processes" are just processes started by
> the system, nothing more.

In this context "system process" means "a process that has evaluated
process_flag(trap_exit, true)"

>
> That exit(kill) and exit(Self, kill) behave differently is *exactly* as it
> should be, they are *defined* to behave differently. exit/2 will *always*
> send an exit signal to the process even if the process itself! Its behaviour
> is consistent. When sending to itself the process should behave as if the
> exit signal came from "outside" the itself. This means that if you are
> trapping exits you should also trap the exits from exit/2 to yourself.
>

Yes - in the book and elsewhere we refer to "signals" and "messages" - but they
are not the same thing. Signals get converted to messages and put into the
inbox of a process if you have said process_flag(tap_exit, true). But the signal
generated by exit(Pid, kill) *never* gets converted to a message.

When c dies by evaluating exit(X) it broadcasts a signal to it's link set
If  b is linked to c it will convert this to the message {'EXIT',Pid,X} this is
true for all X. If c says exit(Pic, kill) a *different kind* of
unstoppable signal
is sent and b must die. Signals are internal things and can never be
printed, we can only print the messages that result form signals being
converted to messages.

The origonal reason for this was to be able to kill rogue processes.
If A wants to
kill B it evaluates exit(B, kill) and we are guaranted that B will
die. If A just says
exit(kill) it says I'm dieing with reason kill.

The distinction between messages and signals is subtle.

If you read section 9.4 subsection "system processes" of my book you'll see this
behavior is described more or less as I have described it above.

Now if you didn't like the above description we can try a different approach

 ---- a different way of describing the same thing

The VM behaves as if there were 3 type of inter-process messages:

      (1, Data)  tuples represent regular messages
      (2, Data)  tuples represent signals
      3              is the kill signal

    P ! X sends a type 1 message  (1,X)
    exit(X) sends  a type 2 message (2,X)
    exit(P, kill) sends a type 3 message
    exit(P, X) sends a type 2 message (2,X)

on receiving a type 2 message if X != normal a normal process dies
on receiving a type 2 message a system process converts this to a (1,X) message
on receiving a type 3 message the receiving process dies unconditionally

--- end

This is reasonably clear - the *problem* is that to describe the
behavior I've had to
suddenly invent an new abstract machine and you have to guess the semantics
of this machine. That's why we try very hard to use terms like signals
and messages
to describe the behavior in an abstract way and not in terms of a VM - because
the description of the VM itself would be pretty large and for most purposes is
not necessary. (( and anyway if I describe the VM in language in L1,
what do I describe
L1 in? L2? and what do I describe L2 in .....)) To make life simple we
try to use
meta-circular descriptions and describe Erlang behavior in terms of
Erlang. Mostly
this works - but for the case of signals and messages is not easy.

 > Oth an exit/1 works "internally". It should behave in the same way as

> erlang:error/1. In fact originally they were the same and there was only
> exit/1. Internal errors also looked the same as exit/1. Things started to
> drift apart when internal errors got stack traces. Now stack traces are a
> Good Thing but it meant that the behaviour of errors and exit/1 diverged.
> Unfortunately, instead of fixing exit/1, which would have been the most
> sensible thing to do, the split was made permanent by adding error/1.
>
> So exit/1 and error/1 should behave in the same way, which is different to
> exit/2.
>
> 'kill' is a little special as we felt we needed something which wasn't
> trappable but at the same time we realised that if it spread in the same way
> as other exit signals then it would be uncontrollable. This is why it was
> decided that when a process received an exit 'kill' signal it should always
> unconditionally die but only resignal 'killed' to its linked processes.
> Whether doing exit(kill) should send a real exit 'kill' signal or only a
> 'killed' signal is an interesting question which I can't remember now what
> we decided. If it sends an exit 'kill' signal then it should behave as a
> real 'kill' signal and be non-trappable.
>
> This definitely something for the Erlang Rationale!

Yup

/Joe

>
> Robert
>
> 2009/10/24 Yan Yan <yan.beijing.china@...>
>
>> 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
>>
>

________________________________________________________________
erlang-questions mailing list. See http://www.erlang.org/faq.html
erlang-questions (at) erlang.org

[Ulf Wiger-3]

Joe Armstrong wrote:
>
> The distinction between messages and signals is subtle.

One way to verify that it is indeed as Joe says:

Eshell V5.6.5  (abort with ^G)
1> P = spawn(fun() -> timer:sleep(infinity) end).
<0.32.0>
2> P ! {'EXIT',self(),foo}.
{'EXIT',<0.30.0>,foo}
3> is_process_alive(P).
true
4> exit(P,foo).
true
5> is_process_alive(P).
false
6>

In other words, you cannot fake an exit signal by sending
an {'EXIT',P,R} message.

BR,
Ulf W
--
Ulf Wiger
CTO, Erlang Training & Consulting Ltd
http://www.erlang-consulting.com

________________________________________________________________
erlang-questions mailing list. See http://www.erlang.org/faq.html
erlang-questions (at) erlang.org

[Tony Rogvall-2]

Just to clarify some details about exit signals and trap_exit problems.

You can fake exit signals if the process is trapping exits (Also the  
name of a web site ;-)

In the code below this is illustrated by starting a process that trap  
exits. Then either do
a exit(P, foo) in test1 or P ! {'EXIT',self(),foo} in test2. Also note  
that setting the process_flag(trap_exit,true)
must be synchronized!!! (yes I stumbled right into it ;-)
Trap exits should be avoided when not 100% designed into the solution.

/Tony

-module(trap).

-compile(export_all).

start() ->
     Main = self(),
     P = spawn(fun() ->
                      process_flag(trap_exit, true),
                      Main ! ok,
                      receive {'EXIT',From,Reason} ->
                              io:format("Exit: ~p ~p\n",[From,Reason])
                      end
              end),
     receive
        ok -> P
     end.

test1() ->
     P = start(),
     exit(P, foo).

test2() ->
     P = start(),
     P ! {'EXIT',self(),foo}.



On 29 okt 2009, at 10.57, Ulf Wiger wrote:

> Joe Armstrong wrote:
>>
>> The distinction between messages and signals is subtle.
>
> One way to verify that it is indeed as Joe says:
>
> Eshell V5.6.5  (abort with ^G)
> 1> P = spawn(fun() -> timer:sleep(infinity) end).
> <0.32.0>
> 2> P ! {'EXIT',self(),foo}.
> {'EXIT',<0.30.0>,foo}
> 3> is_process_alive(P).
> true
> 4> exit(P,foo).
> true
> 5> is_process_alive(P).
> false
> 6>
>
> In other words, you cannot fake an exit signal by sending
> an {'EXIT',P,R} message.
>
> BR,
> Ulf W
> --
> Ulf Wiger
> CTO, Erlang Training & Consulting Ltd
> http://www.erlang-consulting.com
>
> ________________________________________________________________
> erlang-questions mailing list. See http://www.erlang.org/faq.html
> erlang-questions (at) erlang.org
>

________________________________________________________________
erlang-questions mailing list. See http://www.erlang.org/faq.html
erlang-questions (at) erlang.org

[Robert Virding]

2009/10/28 Joe Armstrong <erlang@...>

>
>  ---- a different way of describing the same thing
>
> The VM behaves as if there were 3 type of inter-process messages:
>
>      (1, Data)  tuples represent regular messages
>      (2, Data)  tuples represent signals
>      3              is the kill signal
>
>    P ! X sends a type 1 message  (1,X)
>    exit(X) sends  a type 2 message (2,X)
>    exit(P, kill) sends a type 3 message
>    exit(P, X) sends a type 2 message (2,X)
>
> on receiving a type 2 message if X != normal a normal process dies
> on receiving a type 2 message a system process converts this to a (1,X)
> message
> on receiving a type 3 message the receiving process dies unconditionally
>
> --- end
>

Yes, this is clear and understandable. In these terms I suppose you could
describe the problem as:

When I do exit(Self, kill) it sends a type 3 'kill' signal to myself and
when I die I send type 2 'killed' signals to my linked processes. This is
consistent irrespective to whom I send the kill signal.

BUT when I do exit(kill) I send a type 2 signal with value 'kill' which
doesn't behave as a type 3 'kill' signal though the name is the same. This
is inconsistent, and I don't like inconsistencies. There are two different
solutions: either send out real type 3 kill signals; or send out type 2
'killed' signals as if I had received a type 3 signal. Both are consistent,
but which is best?

This is how I have read the problem.

Robert

[Ulf Wiger-3]

Robert Virding wrote:
>
> BUT when I do exit(kill) I send a type 2 signal with value 'kill' which
> doesn't behave as a type 3 'kill' signal though the name is the same. This
> is inconsistent, and I don't like inconsistencies. There are two different
> solutions: either send out real type 3 kill signals; or send out type 2
> 'killed' signals as if I had received a type 3 signal. Both are consistent,
> but which is best?

Why send out type 3 kill signals?

What is that consistent with?

I think the consistent behaviour would be to send out type 2
'killed' signals.

BR,
Ulf W
--
Ulf Wiger
CTO, Erlang Training & Consulting Ltd
http://www.erlang-consulting.com

________________________________________________________________
erlang-questions mailing list. See http://www.erlang.org/faq.html
erlang-questions (at) erlang.org

[Robert Virding]

2009/10/29 Ulf Wiger <ulf.wiger@...>

> Robert Virding wrote:
>
>>
>> BUT when I do exit(kill) I send a type 2 signal with value 'kill' which
>> doesn't behave as a type 3 'kill' signal though the name is the same. This
>> is inconsistent, and I don't like inconsistencies. There are two different
>> solutions: either send out real type 3 kill signals; or send out type 2
>> 'killed' signals as if I had received a type 3 signal. Both are
>> consistent,
>> but which is best?
>>
>
> Why send out type 3 kill signals?
>
> What is that consistent with?
>
> I think the consistent behaviour would be to send out type 2
> 'killed' signals.

I quite agree Ulf, I think that would be best too. I just wanted some form
of discussion so we could get a change from what it is today so I presented
the two alternatives as I saw them.

Robert