[erlang-questions] Exit signals are funny things

Richard Carlsson carlsson.richard@REDACTED
Fri May 5 21:35:22 CEST 2017


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



        /Richard

2017-05-05 14:32 GMT+02:00 Robert Virding <rvirding@REDACTED>:

> 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. <alex0player@REDACTED> 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 <rvirding@REDACTED> написал(а):
>> >
>> > 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
>> > erlang-questions@REDACTED
>> > http://erlang.org/mailman/listinfo/erlang-questions
>>
>>
>
> _______________________________________________
> 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/20170505/838895b5/attachment.htm>


More information about the erlang-questions mailing list