Why are the registered process names just atoms and only atoms?

nhpip · August 29, 2022, 12:59am

Hello,

A very simple question. Why are the registered process names just atoms and only atoms? Why can’t they be opaque and take pretty much any term?

Thanks

starbelly · August 29, 2022, 1:46am

For register/2, yes this is true. I think this is an excellent question and one which I can not provide an answer for. There’s going to be history involved in the answer surely; and while I can speculate on design decisions; I’d love to hear an answer from someone who knows that history.

That said, you definitely can name processes using any term using global or some other registry (via method).

See :

domi · August 29, 2022, 2:05am

There’s an issue open:

github.com/erlang/otp

ERL-860: erlang:register/2 only accepts atoms as keys

opened 12:38PM - 22 Feb 19 UTC

OTP-Maintainer

team:VM enhancement priority:medium

Original reporter: `essen` Affected version: `Not Specified` Component: `kernel`… Migrated from: https://bugs.erlang.org/browse/ERL-860 --- ``` Old issue but still biting us to this day. It is currently more difficult than it should be to register names for processes started dynamically. * The obvious solution to this problem is using list_to_atom which is dangerous because the atom table is limited. * The typical solution is to use a third party library or write something yourself. Not great for what should be a core feature. * The atom table limit could be improved by implementing EEP 20 but I am unclear as to whether GC atoms can be used as keys in the process registry (can we easily put GC-able terms in there?). * Alternatively extending erlang:register/2 to also accept integers would allow us to generate names dynamically (for example using the result of erlang:phash2 as the key, or via counters). This doesn't sound too difficult to implement but would probably look a little weird in tools. * Otherwise the old structured terms solution which involves copying the terms and will necessarily impact performance. That said, while I can read in the gproc paper section 4.1 that performance is a concern, I wonder in what scenario it is. Since we can't really create names dynamically we end up with many systems that have very small number of registered processes. The performance concerns must be for a few specific use cases. If true, perhaps the best solution would be to have two registry storages, one for atoms and one for structured terms. We already test that the term is an atom[1] so this would add zero overhead in that case; it only would for the structured key cases. I am also wondering whether there is a benefit to using the current registry data structure instead of reusing the ets code (at least in the case where structured keys would be allowed). The ets code has seen a lot more performance improvements than erlang:register/2 including read/write concurrency so maybe it would be an improvement to switch to an internal, always existing, ets table. If erlang:register/2 starts allowing any term (because it's easier to not have restrictions, for example), it will at the very least have to reject pid() because that would make the ! syntax non-obvious (though ! could also just be restricted to atoms as well). Opening first and foremost because I did not see it in the tickets, though I could be interested in implementing something depending on the complexity of the preferred solution or guidance opportunities. [1] https://github.com/erlang/otp/blob/master/erts/emulator/beam/register.c#L178 ```

seudin.kasumovic · August 29, 2022, 7:59pm

Maybe you will find this project interesting: GitHub - uwiger/gproc: Extended process registry for Erlang