[erlang-questions] An answer: how does SASL know that a process died?
Richard Carlsson
carlsson.richard@REDACTED
Fri Nov 1 10:41:40 CET 2013
This could be improved by making it work in the same way as undefined
functions etc.: by defining that a particular function in the
error_handler module gets called with the error information as
arguments. Then the formatting and sending to error_logger can be done
in Erlang code, making it much more transparent and easier to change
what it does, and no longer hard-coding a connection in the VM between
process termination and a high level service like the logger. You can
even avoid the whole send operation if you just want to drop these events.
/Richard
On 2013-11-01 02:46 , Robert Virding wrote:
> No, how the error_handler works is well defined, it is written in erlang, and you can affect what it does. Which are 3 things the sending of messages to error_logger is not. You can also directly SEE what the error_handler does.
>
> Robert
>
> ----- Original Message -----
>> From: "Anthony Ramine" <n.oxyde@REDACTED>
>> To: "Robert Virding" <robert.virding@REDACTED>
>> Cc: "Richard Carlsson" <carlsson.richard@REDACTED>, "Erlang Questions" <erlang-questions@REDACTED>
>> Sent: Thursday, 31 October, 2013 4:25:47 PM
>> Subject: Re: [erlang-questions] An answer: how does SASL know that a process died?
>>
>> Would you get rid of error_handler too? Because I find that worse than the
>> error_logger situation. At least a logger is just a logger, it can’t
>> masquerade a function call as another one or do fancy things like this.
>>
>> --
>> Anthony Ramine
>>
>> Le 31 oct. 2013 à 16:12, Robert Virding <robert.virding@REDACTED>
>> a écrit :
>>
>>> What a stupid thing for the system to do! Erlang is Erlang and OTP is
>>> something on top of Erlang. It was never written into the spec because we
>>> didn't know about it. How can we get rid of it? It is definitely a bug, at
>>> best a bad design decision!
>>
>>
More information about the erlang-questions
mailing list