Re: Semantic Monitors: a proposal

On 2/17/21 2:03 AM, Lukas Larsson wrote:
>
>
> On Wed, Feb 17, 2021 at 10:34 AM Viktor Söderqvist 
> <[email protected] <mailto:[email protected]>> wrote:
>
>     Hello!
>
>     On 2021-02-17 08:07, Lukas Larsson wrote:
>     > You are in luck!
>     >
>     > PR-2735[1] aka EEP-53[2] adds erlang:monitor/3[3] which can be
>     used to
>     > do what you want. It will be released in Erlang/OTP 24.
>     >
>     > [1]: https://github.com/erlang/otp/pull/2735
>     > [2]: https://github.com/erlang/eep/blob/master/eeps/eep-0053.md
>     > [3]:
>     >
>     https://erlang.org/~rickard/OTP-16718/erts-11.1.1/doc/html/erlang.html#monitor-3
>
>
>     Nice! But Michael's use case would require an extra monitor option.
>
>     On 2/16/21 1:14 PM, Michael Truog wrote:
>      > 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).
>
>     For example {tag_fun, fun() -> {'DOWN', erlang:monotonic_time()}
>     end} or
>     so, to create the tag at the time of demotinor time. I suppose there
>     will still be a short time between the death of the process and the
>     creation of the tag though.
>
>
> I don't think we want to enable executing code in the context of an 
> already dead or dying process. What happens if the code does a 
> gen_server:call? What happens if it does gen_server:enter_loop? Could 
> a process be resurrected?
>
> There are also a lot of assumptions within the VM that a dead process 
> does not execute code, so it would a lot of work to do.
Is there interest in adding the native monotonic time to the monitor 
DOWN message due to a separate option?  It should be beneficial to have 
a more accurate time-of-process-death value than is currently possible 
when the DOWN message is received.

Best Regards,
Michael