Semantic Monitors: a proposal

Michael Truog mjtruog@REDACTED
Tue Feb 16 22:54:55 CET 2021

Using a string this way wouldn't be a good approach due to a lack of 
visibility and quick evaluation (the expand function only works for 
data, not evaluating functions).  Providing an anonymous function for 
evaluation would be the proper approach:  fun erlang:monotonic_time/0. 
So, I am suggesting allowing function evaluation when the DOWN message 
is created unless the monotonic time could be added to the DOWN message 
due to a separate option.

On 2/16/21 1:14 PM, Michael Truog wrote:
> Hi Guilherme,
> I have mainly wanted to get the native monotonic time added to monitor 
> messages because of a monitor creation option, to avoid any variation 
> due to Erlang process message queue delays (so the monotonic time 
> value would be stored when the DOWN message is created, equivalent to 
> a erlang:monotonic_time/0 function call).
> If it was possible to provide the data as a string, like 
> "erlang:monotonic_time()" to get evaluated when the DOWN message is 
> created, that would make me happy though it may seem like an odd 
> approach that adds extra latency (it could be a separate option).  The 
> evaluation could be similar to the expand function below:
> expand(L) ->
>     {ok, S, _} = erl_scan:string(L ++ "."),
>     case erl_parse:parse_term(S) of
>         {ok, Term} ->
>             Term;
>         {error, _} ->
>             badarg
>     end.
> I would want to avoid using a NIF outside of Erlang/OTP for this 
> functionality, to keep all the core logic as Erlang source code.  
> Adding the monotonic time to a monitor DOWN message helps to ensure 
> you have the time of the process death in a consistent way where the 
> time isn't being influenced by the Erlang process receiving the DOWN 
> message (which remains completely separate and unrelated to the 
> process that died).
> Best Regards,
> Michael
> On 2/16/21 9:32 AM, Guilherme Andrade wrote:
>> Hello list,
>> I've spent years writing boilerplate for associating process monitors 
>> with other identifiers and react appropriately (and performantly) 
>> when one of those processes terminates.
>> But: what if we could attach data to a monitor and get it back in its 
>> DOWN message?
>> You'd optionally associate data to a monitor when creating it:
>>     * Ref = monitor(process, Pid, [{data, {user_id, <<"12345">>}}])
>> And you'd get it back upon the monitor being triggered:
>>     * {'DOWN', Ref, process, Pid, Reason, {user_id, <<"12345">>}}
>> Regular monitors would still work the same way and keep the current 
>> DOWN message format - nothing would break.
>> I've explored this concept using NIFs and published the result to GitHub:
>>     *
>> Is this a good idea? If so, would it be feasible to implement it in 
>> OTP? Should there be an EEP first? I'd be willing to contribute to 
>> either.
>> Any input is welcome.
>> Cheers!
>> -- 
>> Guilherme

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the erlang-questions mailing list