Semantic Monitors: a proposal

Michael Truog mjtruog@REDACTED
Tue Feb 16 22:14:31 CET 2021

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} ->
         {error, _} ->

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,

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