search

rabbitmq / ra

A Raft implementation for Erlang and Elixir that strives to be efficient and make it easier to use multiple Raft clusters in a single system.
Other
811 stars 96 forks source link

Named monitors #31

Open hairyhum opened 5 years ago

hairyhum commented 5 years ago

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 commented 5 years ago

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

hairyhum commented 5 years ago

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

kjnilsson commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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.