Named monitors

[hairyhum]

Since monitors are supposed to be effects, it's not possible to take a monitor reference and save it in the state. When a machine needs to monitor more than one type of entity it has to scan through all of them to find the process which was monitored.
It would be nice to have some monitor references to keep dispatch code clean.

Example:
Monitor entity type1: {monitor, process, entity1, Pid1}
Monitor entity type2: {monitor, process, entity2, Pid2}

Handle down signal for entity1:

apply(Meta, _E, {down, entity1, Pid, Reason}) ->

WDYT?

[kjnilsson]

Can you just keep a map of Pid => Entity?

[hairyhum]

The idea was about simplifying the machine code, and keeping the map in the state would be the opposite for my opinion.

[kjnilsson]

If anything it complicates the API for machine implementors as they already have a unique identifier in the pid and now need to provide yet another arbitrary one. Since you cannot use generators inside the state machine code this could become tricky. Is it that hard to maintain a map for your use case? What are these entities in your example? Do they ever restart?

[hairyhum]

The identifier would not be unique. It would be from a predefined set. I should have explained it better.
Let's say you monitor two kinds of processes. Then you will have to save pids in two containers (maps or lists or sets) and on down message you will have to search both of them to dispatch the call. This proposal is to improve that dispatch moving it to the function clause level.

[kjnilsson]

Ok I sortof get what you are asking for but there is no need to search if you maintain a map like #{pid() => entity1 | entity2} right? you are basically asking ra to do that for you is that right?

Ra only maintains one monitor for each pid (unlike erlang) what should the logic be when it receives two monitor effects for the same pid but different entities? Should that result in two down commands being committed?

I am still not sure about this feature as it is so simple to just maintain inside the state machine.

[hairyhum]

Ra already maintains a map of pids and monitor refs. So complexity here is when machine tries to issue monitors for different types but the same pid. Technically it should not do that, but it would be hard to enforce, yes.