Quantcast

Exit signals are funny things

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Exit signals are funny things

Robert Virding
So:

1> Pid = spawn_link(fun() -> timer:sleep(infinity) end).
<0.59.0>
2> exit(Pid, normal).
true
3> flush().      
ok
4> exit(Pid, die).
** exception exit: die

I spawn_link a process which is not trapping and send it the signal 'normal' which it ignores. As it should. I then send it the signal 'die' and it crashes. As it should.

Now:

5> exit(self(), normal).
** exception exit: normal

Now I send myself the signal 'normal' and I die! So there is 'normal' and there is 'normal' depending on to whom I send it.

Where's the logic in that?

Robert

P.S. More to come


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Exit signals are funny things

Brujo Benavides-2
Furthermore…

1> Self = self().
<0.68.0>
2> spawn(fun() -> exit(Self, normal) end).
<0.71.0>
3> flush().
ok
4> self().
<0.68.0>
5> spawn(fun() -> exit(Self, not_normal) end).
** exception exit: not_normal
6> self().
<0.76.0>
7>

So, if some other process sends me a normal exit signal, it works as expected.

On May 3, 2017, at 14:03, Robert Virding <[hidden email]> wrote:

So:

1> Pid = spawn_link(fun() -> timer:sleep(infinity) end).
<0.59.0>
2> exit(Pid, normal).
true
3> flush().      
ok
4> exit(Pid, die).
** exception exit: die

I spawn_link a process which is not trapping and send it the signal 'normal' which it ignores. As it should. I then send it the signal 'die' and it crashes. As it should.

Now:

5> exit(self(), normal).
** exception exit: normal

Now I send myself the signal 'normal' and I die! So there is 'normal' and there is 'normal' depending on to whom I send it.

Where's the logic in that?

Robert

P.S. More to come

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Exit signals are funny things

Valentin Micic-2
In reply to this post by Robert Virding
> Now:
>
> 5> exit(self(), normal).
> ** exception exit: normal

Death is a normal thing. Suicide, not so much. ;-)

V/
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Exit signals are funny things

Ben Murphy-2
In reply to this post by Robert Virding
Well its a very deliberate decision by someone.

erts/emulator/beam/bif.c:

         erts_send_exit_signal(BIF_P,
                               BIF_P->common.id,
                               rp,
                               &rp_locks,
                               BIF_ARG_2,
                               NIL,
                               NULL,
                               BIF_P == rp ? ERTS_XSIG_FLG_NO_IGN_NORMAL : 0);

It sends ERTS_XSIG_FLG_NO_IGN_NORMAL if you are sending a signal to yourself.

On Wed, May 3, 2017 at 2:03 PM, Robert Virding <[hidden email]> wrote:

> So:
>
> 1> Pid = spawn_link(fun() -> timer:sleep(infinity) end).
> <0.59.0>
> 2> exit(Pid, normal).
> true
> 3> flush().
> ok
> 4> exit(Pid, die).
> ** exception exit: die
>
> I spawn_link a process which is not trapping and send it the signal 'normal'
> which it ignores. As it should. I then send it the signal 'die' and it
> crashes. As it should.
>
> Now:
>
> 5> exit(self(), normal).
> ** exception exit: normal
>
> Now I send myself the signal 'normal' and I die! So there is 'normal' and
> there is 'normal' depending on to whom I send it.
>
> Where's the logic in that?
>
> Robert
>
> P.S. More to come
>
>
> _______________________________________________
> erlang-questions mailing list
> [hidden email]
> http://erlang.org/mailman/listinfo/erlang-questions
>
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Exit signals are funny things

Robert Virding
Sigh, that means someone has been "thinking".

Robert


On 3 May 2017 at 18:05, Ben Murphy <[hidden email]> wrote:
Well its a very deliberate decision by someone.

erts/emulator/beam/bif.c:

         erts_send_exit_signal(BIF_P,
                               BIF_P->common.id,
                               rp,
                               &rp_locks,
                               BIF_ARG_2,
                               NIL,
                               NULL,
                               BIF_P == rp ? ERTS_XSIG_FLG_NO_IGN_NORMAL : 0);

It sends ERTS_XSIG_FLG_NO_IGN_NORMAL if you are sending a signal to yourself.

On Wed, May 3, 2017 at 2:03 PM, Robert Virding <[hidden email]> wrote:
> So:
>
> 1> Pid = spawn_link(fun() -> timer:sleep(infinity) end).
> <0.59.0>
> 2> exit(Pid, normal).
> true
> 3> flush().
> ok
> 4> exit(Pid, die).
> ** exception exit: die
>
> I spawn_link a process which is not trapping and send it the signal 'normal'
> which it ignores. As it should. I then send it the signal 'die' and it
> crashes. As it should.
>
> Now:
>
> 5> exit(self(), normal).
> ** exception exit: normal
>
> Now I send myself the signal 'normal' and I die! So there is 'normal' and
> there is 'normal' depending on to whom I send it.
>
> Where's the logic in that?
>
> Robert
>
> P.S. More to come
>
>
> _______________________________________________
> erlang-questions mailing list
> [hidden email]
> http://erlang.org/mailman/listinfo/erlang-questions
>


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Exit signals are funny things

Robert Virding
There is more. So:

1> process_flag(trap_exit, true).
false
2> Pid = spawn_link(fun() -> process_flag(trap_exit,true), timer:sleep(infinity) end).
<0.60.0>

We trap exits and spawn_link which also traps exits and just hangs there waiting.

3> spawn(fun() -> link(Pid), exit(kill) end).
<0.62.0>
4> process_info(Pid, messages).
{messages,[{'EXIT',<0.62.0>,kill}]}

Now we spawn a new process which links to our hanger and exits with the reason 'kill'. We can then check our hanger and see that it received a 'kill' signal which it converted to a message because it was trapping. Finally:

5> spawn(fun() -> exit(Pid, kill) end).
<0.65.0>
6> flush().
Shell got {'EXIT',<0.60.0>,killed}
ok

we spawn another process which uses exit/2 to send a 'kill' signal to our hanger and in this case it cannot trap the signal and dies with the reason 'killed'. So there is 'kill' and 'kill' depending on how I send it.

Where's the logic in that?

Robert

P.S. Yes, I know that getting a 'killed' from a process which has been killed with a 'kill' signal is the correct.


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Exit signals are funny things

Alex S.
There is exit/1 and exit/2 which are very, very different things. exit/1 is NOT an exit signal.
There is no “kill and kill”, there is exit signal kill, which is special, and exit reason kill, which is not special.

> 5 мая 2017 г., в 15:05, Robert Virding <[hidden email]> написал(а):
>
> There is more. So:
>
> 1> process_flag(trap_exit, true).
> false
> 2> Pid = spawn_link(fun() -> process_flag(trap_exit,true), timer:sleep(infinity) end).
> <0.60.0>
>
> We trap exits and spawn_link which also traps exits and just hangs there waiting.
>
> 3> spawn(fun() -> link(Pid), exit(kill) end).
> <0.62.0>
> 4> process_info(Pid, messages).
> {messages,[{'EXIT',<0.62.0>,kill}]}
>
> Now we spawn a new process which links to our hanger and exits with the reason 'kill'. We can then check our hanger and see that it received a 'kill' signal which it converted to a message because it was trapping. Finally:
>
> 5> spawn(fun() -> exit(Pid, kill) end).
> <0.65.0>
> 6> flush().
> Shell got {'EXIT',<0.60.0>,killed}
> ok
>
> we spawn another process which uses exit/2 to send a 'kill' signal to our hanger and in this case it cannot trap the signal and dies with the reason 'killed'. So there is 'kill' and 'kill' depending on how I send it.
>
> Where's the logic in that?
>
> Robert
>
> P.S. Yes, I know that getting a 'killed' from a process which has been killed with a 'kill' signal is the correct.
>
> _______________________________________________
> erlang-questions mailing list
> [hidden email]
> http://erlang.org/mailman/listinfo/erlang-questions

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Exit signals are funny things

Robert Virding
Yes, and no. When a process dies with a reason then that reason is sent in a signal to all the processes in the link set. So if the process dies with the reason 'foo' then a 'foo' exit signal will be sent, and if I do exit/2 to send a 'foo' exit signal then a 'foo' exit signal will be sent. In both cases, if the receiving process is not trapping it will die with the reason 'foo' [*] and if the receiving process is trapping then the exit signal will be converted to a message with reason 'foo'. In both cases it IS a 'foo' exit signal.

However, if the exit reason is 'kill' then the 'kill' exit signal sent from the process will be trapped while if it is sent with exit/2 it is not trappable. THIS IS THE ONLY EXIT SIGNAL WHICH BEHAVES DIFFERENTLY! [**]

Again where's the logic in that? Why the inconsistency? We tried hard back in the old days to be consistent.

Robert

* As 'foo' is not the value 'normal' it will kill the process.
**Sorry of raising my voice.


On 5 May 2017 at 14:08, Alex S. <[hidden email]> wrote:
There is exit/1 and exit/2 which are very, very different things. exit/1 is NOT an exit signal.
There is no “kill and kill”, there is exit signal kill, which is special, and exit reason kill, which is not special.
> 5 мая 2017 г., в 15:05, Robert Virding <[hidden email]> написал(а):
>
> There is more. So:
>
> 1> process_flag(trap_exit, true).
> false
> 2> Pid = spawn_link(fun() -> process_flag(trap_exit,true), timer:sleep(infinity) end).
> <0.60.0>
>
> We trap exits and spawn_link which also traps exits and just hangs there waiting.
>
> 3> spawn(fun() -> link(Pid), exit(kill) end).
> <0.62.0>
> 4> process_info(Pid, messages).
> {messages,[{'EXIT',<0.62.0>,kill}]}
>
> Now we spawn a new process which links to our hanger and exits with the reason 'kill'. We can then check our hanger and see that it received a 'kill' signal which it converted to a message because it was trapping. Finally:
>
> 5> spawn(fun() -> exit(Pid, kill) end).
> <0.65.0>
> 6> flush().
> Shell got {'EXIT',<0.60.0>,killed}
> ok
>
> we spawn another process which uses exit/2 to send a 'kill' signal to our hanger and in this case it cannot trap the signal and dies with the reason 'killed'. So there is 'kill' and 'kill' depending on how I send it.
>
> Where's the logic in that?
>
> Robert
>
> P.S. Yes, I know that getting a 'killed' from a process which has been killed with a 'kill' signal is the correct.
>
> _______________________________________________
> erlang-questions mailing list
> [hidden email]
> http://erlang.org/mailman/listinfo/erlang-questions



_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Exit signals are funny things

Alex S.
I think the logic is in the different explicit intent, which is present when exit/2ing someothing with ‘kill’, but absent when crashing with ‘kill’. Besides, crashing with ‘kill’ behaving “consistently” would mean broadcasting a brutal kill, which is rarely, if ever, desirable.
5 мая 2017 г., в 15:32, Robert Virding <[hidden email]> написал(а):

Yes, and no. When a process dies with a reason then that reason is sent in a signal to all the processes in the link set. So if the process dies with the reason 'foo' then a 'foo' exit signal will be sent, and if I do exit/2 to send a 'foo' exit signal then a 'foo' exit signal will be sent. In both cases, if the receiving process is not trapping it will die with the reason 'foo' [*] and if the receiving process is trapping then the exit signal will be converted to a message with reason 'foo'. In both cases it IS a 'foo' exit signal.

However, if the exit reason is 'kill' then the 'kill' exit signal sent from the process will be trapped while if it is sent with exit/2 it is not trappable. THIS IS THE ONLY EXIT SIGNAL WHICH BEHAVES DIFFERENTLY! [**]

Again where's the logic in that? Why the inconsistency? We tried hard back in the old days to be consistent.

Robert

* As 'foo' is not the value 'normal' it will kill the process.
**Sorry of raising my voice.


On 5 May 2017 at 14:08, Alex S. <[hidden email]> wrote:
There is exit/1 and exit/2 which are very, very different things. exit/1 is NOT an exit signal.
There is no “kill and kill”, there is exit signal kill, which is special, and exit reason kill, which is not special.
> 5 мая 2017 г., в 15:05, Robert Virding <[hidden email]> написал(а):
>
> There is more. So:
>
> 1> process_flag(trap_exit, true).
> false
> 2> Pid = spawn_link(fun() -> process_flag(trap_exit,true), timer:sleep(infinity) end).
> <0.60.0>
>
> We trap exits and spawn_link which also traps exits and just hangs there waiting.
>
> 3> spawn(fun() -> link(Pid), exit(kill) end).
> <0.62.0>
> 4> process_info(Pid, messages).
> {messages,[{'EXIT',<0.62.0>,kill}]}
>
> Now we spawn a new process which links to our hanger and exits with the reason 'kill'. We can then check our hanger and see that it received a 'kill' signal which it converted to a message because it was trapping. Finally:
>
> 5> spawn(fun() -> exit(Pid, kill) end).
> <0.65.0>
> 6> flush().
> Shell got {'EXIT',<0.60.0>,killed}
> ok
>
> we spawn another process which uses exit/2 to send a 'kill' signal to our hanger and in this case it cannot trap the signal and dies with the reason 'killed'. So there is 'kill' and 'kill' depending on how I send it.
>
> Where's the logic in that?
>
> Robert
>
> P.S. Yes, I know that getting a 'killed' from a process which has been killed with a 'kill' signal is the correct.
>
> _______________________________________________
> erlang-questions mailing list
> [hidden email]
> http://erlang.org/mailman/listinfo/erlang-questions




_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Exit signals are funny things

Richard Carlsson-3
In reply to this post by Robert Virding
This stuff has been up several times before. Here's one from 2009 where I looked into it:

Then there's this one from 2010 where Robert answered: http://erlang.org/pipermail/erlang-questions/2010-December/055003.html


   /Richard



        /Richard

2017-05-05 14:32 GMT+02:00 Robert Virding <[hidden email]>:
Yes, and no. When a process dies with a reason then that reason is sent in a signal to all the processes in the link set. So if the process dies with the reason 'foo' then a 'foo' exit signal will be sent, and if I do exit/2 to send a 'foo' exit signal then a 'foo' exit signal will be sent. In both cases, if the receiving process is not trapping it will die with the reason 'foo' [*] and if the receiving process is trapping then the exit signal will be converted to a message with reason 'foo'. In both cases it IS a 'foo' exit signal.

However, if the exit reason is 'kill' then the 'kill' exit signal sent from the process will be trapped while if it is sent with exit/2 it is not trappable. THIS IS THE ONLY EXIT SIGNAL WHICH BEHAVES DIFFERENTLY! [**]

Again where's the logic in that? Why the inconsistency? We tried hard back in the old days to be consistent.

Robert

* As 'foo' is not the value 'normal' it will kill the process.
**Sorry of raising my voice.


On 5 May 2017 at 14:08, Alex S. <[hidden email]> wrote:
There is exit/1 and exit/2 which are very, very different things. exit/1 is NOT an exit signal.
There is no “kill and kill”, there is exit signal kill, which is special, and exit reason kill, which is not special.
> 5 мая 2017 г., в 15:05, Robert Virding <[hidden email]> написал(а):
>
> There is more. So:
>
> 1> process_flag(trap_exit, true).
> false
> 2> Pid = spawn_link(fun() -> process_flag(trap_exit,true), timer:sleep(infinity) end).
> <0.60.0>
>
> We trap exits and spawn_link which also traps exits and just hangs there waiting.
>
> 3> spawn(fun() -> link(Pid), exit(kill) end).
> <0.62.0>
> 4> process_info(Pid, messages).
> {messages,[{'EXIT',<0.62.0>,kill}]}
>
> Now we spawn a new process which links to our hanger and exits with the reason 'kill'. We can then check our hanger and see that it received a 'kill' signal which it converted to a message because it was trapping. Finally:
>
> 5> spawn(fun() -> exit(Pid, kill) end).
> <0.65.0>
> 6> flush().
> Shell got {'EXIT',<0.60.0>,killed}
> ok
>
> we spawn another process which uses exit/2 to send a 'kill' signal to our hanger and in this case it cannot trap the signal and dies with the reason 'killed'. So there is 'kill' and 'kill' depending on how I send it.
>
> Where's the logic in that?
>
> Robert
>
> P.S. Yes, I know that getting a 'killed' from a process which has been killed with a 'kill' signal is the correct.
>
> _______________________________________________
> erlang-questions mailing list
> [hidden email]
> http://erlang.org/mailman/listinfo/erlang-questions



_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions



_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Exit signals are funny things

Leo Liu-2
On 2017-05-05 21:35 +0200, Richard Carlsson wrote:

> This stuff has been up several times before. Here's one from 2009 where I
> looked into it:
> http://erlang.org/pipermail/erlang-questions/2009-October/047190.html
>
> Then there's this one from 2010 where Robert answered:
> http://erlang.org/pipermail/erlang-questions/2010-December/055003.html
>
> And here's one from 2015 started by Robert:
> http://erlang.org/pipermail/erlang-questions/2015-October/086289.html
>
>    /Richard

All of these seem making sense. There is this little thing that is
confusing.

1> spawn_link(fun () -> exit(kill) end).
** exception exit: killed

exit(kill) is unlike other exit(Reason) i.e. it's rewritten as `killed'.

Leo

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Exit signals are funny things

Robert Virding
In reply to this post by Richard Carlsson-3
Yes, I know but the problem is still there. And I still get annoyed with the inconsistency every time I think about it. :-)

Robert


On 5 May 2017 at 21:35, Richard Carlsson <[hidden email]> wrote:
This stuff has been up several times before. Here's one from 2009 where I looked into it:

Then there's this one from 2010 where Robert answered: http://erlang.org/pipermail/erlang-questions/2010-December/055003.html


   /Richard



        /Richard

2017-05-05 14:32 GMT+02:00 Robert Virding <[hidden email]>:
Yes, and no. When a process dies with a reason then that reason is sent in a signal to all the processes in the link set. So if the process dies with the reason 'foo' then a 'foo' exit signal will be sent, and if I do exit/2 to send a 'foo' exit signal then a 'foo' exit signal will be sent. In both cases, if the receiving process is not trapping it will die with the reason 'foo' [*] and if the receiving process is trapping then the exit signal will be converted to a message with reason 'foo'. In both cases it IS a 'foo' exit signal.

However, if the exit reason is 'kill' then the 'kill' exit signal sent from the process will be trapped while if it is sent with exit/2 it is not trappable. THIS IS THE ONLY EXIT SIGNAL WHICH BEHAVES DIFFERENTLY! [**]

Again where's the logic in that? Why the inconsistency? We tried hard back in the old days to be consistent.

Robert

* As 'foo' is not the value 'normal' it will kill the process.
**Sorry of raising my voice.


On 5 May 2017 at 14:08, Alex S. <[hidden email]> wrote:
There is exit/1 and exit/2 which are very, very different things. exit/1 is NOT an exit signal.
There is no “kill and kill”, there is exit signal kill, which is special, and exit reason kill, which is not special.
> 5 мая 2017 г., в 15:05, Robert Virding <[hidden email]> написал(а):
>
> There is more. So:
>
> 1> process_flag(trap_exit, true).
> false
> 2> Pid = spawn_link(fun() -> process_flag(trap_exit,true), timer:sleep(infinity) end).
> <0.60.0>
>
> We trap exits and spawn_link which also traps exits and just hangs there waiting.
>
> 3> spawn(fun() -> link(Pid), exit(kill) end).
> <0.62.0>
> 4> process_info(Pid, messages).
> {messages,[{'EXIT',<0.62.0>,kill}]}
>
> Now we spawn a new process which links to our hanger and exits with the reason 'kill'. We can then check our hanger and see that it received a 'kill' signal which it converted to a message because it was trapping. Finally:
>
> 5> spawn(fun() -> exit(Pid, kill) end).
> <0.65.0>
> 6> flush().
> Shell got {'EXIT',<0.60.0>,killed}
> ok
>
> we spawn another process which uses exit/2 to send a 'kill' signal to our hanger and in this case it cannot trap the signal and dies with the reason 'killed'. So there is 'kill' and 'kill' depending on how I send it.
>
> Where's the logic in that?
>
> Robert
>
> P.S. Yes, I know that getting a 'killed' from a process which has been killed with a 'kill' signal is the correct.
>
> _______________________________________________
> erlang-questions mailing list
> [hidden email]
> http://erlang.org/mailman/listinfo/erlang-questions



_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions




_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Loading...