<html>
<head>
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
</head>
<body>
<div class="moz-cite-prefix">Hi Guilherme,<br>
<br>
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 <span class="pl-en">erlang</span>:<span
class="pl-en">monotonic_time/0 function call).<br>
<br>
If it was possible to provide the data as a string, like "</span><span
class="pl-en"><span class="pl-en">erlang</span>:<span
class="pl-en">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:<br>
<br>
expand(L) -><br>
{ok, S, _} = erl_scan:string(L ++ "."),<br>
case erl_parse:parse_term(S) of<br>
{ok, Term} -><br>
Term;<br>
{error, _} -><br>
badarg<br>
end.<br>
<br>
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).<br>
<br>
Best Regards,<br>
Michael<br>
<br>
</span></span>On 2/16/21 9:32 AM, Guilherme Andrade wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAA5f+NV=pRrcR5xeovWE0mPv80k1eVQooubRvumtPP-O7Wr6rA@mail.gmail.com">
<meta http-equiv="content-type" content="text/html;
charset=windows-1252">
<div dir="ltr">
<div>Hello list,</div>
<div><br>
</div>
<div>I've spent years writing boilerplate for associating
process monitors with other identifiers and react
appropriately (and performantly) when one of those processes
terminates.<br>
</div>
<div><br>
</div>
<div>But: what if we could attach data to a monitor and get it
back in its DOWN message?</div>
<div><br>
</div>
<div>You'd optionally associate data to a monitor when creating
it:<br>
</div>
<div> * Ref = monitor(process, Pid, [{data, {user_id,
<<"12345">>}}])</div>
<div><br>
</div>
<div>And you'd get it back upon the monitor being triggered:<br>
</div>
<div> * {'DOWN', Ref, process, Pid, Reason, {user_id,
<<"12345">>}}</div>
<div><br>
</div>
<div>Regular monitors would still work the same way and keep the
current DOWN message format - nothing would break.</div>
<div><br>
</div>
<div>I've explored this concept using NIFs and published the
result to GitHub:<br>
* <a href="https://github.com/g-andrade/vaktari"
moz-do-not-send="true">https://github.com/g-andrade/vaktari</a></div>
<div><br>
</div>
<div>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.<br>
</div>
<div><br>
</div>
<div>Any input is welcome.</div>
<div><br>
</div>
<div>Cheers!<br>
</div>
<div><br>
-- <br>
<div dir="ltr" class="gmail_signature"
data-smartmail="gmail_signature">
<div dir="ltr">
<div>
<div dir="ltr">
<div>
<div dir="ltr">Guilherme<br>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<br>
</body>
</html>