[erlang-questions] 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 <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 <mailto: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 <mailto: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 <mailto:erlang-questions@REDACTED>
> > http://erlang.org/mailman/listinfo/erlang-questions <http://erlang.org/mailman/listinfo/erlang-questions>
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20170505/7c59047a/attachment.htm>