Semantic Monitors: a proposal

[Michael Truog]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20210216/72f760ad/attachment.htm>