Improved performance for 1 partition (most common case)
Allow a process to update its own value
Support for named listeners
Allow metadata to be stored along-side the registry
The last two features should make the registry more extensible. Listeners allows you to give a named process when the registry is started that will receive events whenever a process registers or unregisters a key. You could use those features to add Await support to the registry or even use the registry as a pool. We have added an example of using the registry as a sojourn pool to the examples directory. The pool is an example, do not use it in production:
The pool above measures the sojourn time, which is how long messages stay in each pooled process queue. That provides an idea of how fast processes are responding. Whenever there is a dispatch, we pick two random pooled processes and choose the one with the most recent reply and smaller sojourn time.
The pool itself works by starting a worker and a registry. The worker is a listener of the registry and a supervisor guarantees that both are restarted in case any of crashes. Whenever a new process is added to the registry, the worker is notified and starts sending sampling messages to that process which updates its own entry in case of crashes.
I hope it serves as inspiration for playing with the registry for other use cases.
I was taking a look at the code and was puzzled over two things:
First one is, why use a positional argument for the registry name, rather than using the convention of passing name in the keyword list options.
The second one is the reasoning for defining multiple modules inside the same file? I was trying to locate Registry.Supervisor and it took me a while to understand it was in the file rather then in a Registry folder.
Is there a convention in place for cases like this?
Doesn’t global predate the Elixir Registry and this whole thread by years? I think that @josevalim was referring to something else. Still, I couldn’t see reference to any new work in progress in the global docs.
Recently, attempts have been made to resolve the problems of Distributed Erlang: SD-Erlang and Ericsson’s planned port of global to the Kademlia DHT are focused on reducing the amount of information that each node in the global registry needs to replicate, but that only temporarily mitigates the problem.