[erlang-questions] Exit signals are funny things
Robert Virding
rvirding@REDACTED
Mon May 8 23:38:01 CEST 2017
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 <carlsson.richard@REDACTED> 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
>
>
>
> /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/20170508/41b912f2/attachment.htm>
More information about the erlang-questions
mailing list