Re: Semantic Monitors: a proposal

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:
>>     * https://github.com/g-andrade/vaktari
>>
>> 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
>