I am building an application that manages workers, these workers are simple GenServers with an state.
I have a separated process that keeps tracks of all the workers, basically this process is another GenServer that monitors the workers adding and removing pids from his state. I am using Process.monitor to do so.
I have a DynamicSupervisor that supervises the workers…
The problem is that when the supervisor restarts a worker I want to update the state of the monitor genserver by updating the old pid with the new one.
Process.monitor only notifies when the process dies and provides the old pid but I need the new pid to replace the old one.
Instead of keeping pid in a separate GenServer, You might use Registry. It will allow You to map pid by key. This solution will work in local, then You might switch for :global when going distributed.
Or send a (register) message when the worker starts?!
I think that this points in the right direction, at least in the beginning. Registry is a more advanced use case. It may be best to start with a more restricted named process.
It probably makes the most sense that it’s the monitoring process that is named. Typically worker processes are kept fairly generic. So the worker processes would have to “check in” (register) with the monitoring process. In terms of supervision an additional supervisor may be required to ensure that the monitoring process is up and running before any of the workers start. A :rest_for_one supervisor could start up the monitoring process first and the DynamicSupervisor second.
Each worker process needs to check in with the named monitoring process before it does anything else. However a server’s init/1 callback is supposed to be kept as short/fast as possible as it will block the process that is calling start_link/3/start/3. So it would be best to return the new {:ok, state, {:continue, continue}} value from init/1.
That will cause the handle_continue/2 callback to run - from within the new process (not under the start_link/3/start/3 process). Here the new process can call/3 the monitoring process by name. A cast/2 wouldn’t ensure that the monitor process is 1) up and running and 2) has processed the message. Once that call/3 completes successfully the worker process is free to go about it’s regular job.
When the monitoring process receives a worker’s registration message it can use Process.monitor/1 to be notified when that particular process goes :DOWN so that it can be cleaned out of the monitoring process’s state.
