<div dir="ltr"><div><br class="gmail-Apple-interchange-newline">>>When one of the main languages rolls their own in the stdlib, it is one of many signals that adopting it in the core may be worth it.</div><div>>>At the same time, I understand that the OTP team may not want the additional maintenance workload.<br></div><div><br></div><div>Those claims without evidence look like manipulation. </div><div>And how does a library for processes dictionaries look up is connected with the theme of this topic?<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">вс, 9 мая 2021 г. в 16:32, Thomas Depierre <<a href="mailto:depierre.thomas@gmail.com">depierre.thomas@gmail.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>
It may be worth pointing out that Elixir rolled out a Registry in their stdlib that does it because well it needed it. <a href="https://hexdocs.pm/elixir/Registry.html" target="_blank">https://hexdocs.pm/elixir/Registry.html</a></div><div><br></div><div>When one of the main languages rolls their own in the stdlib, it is one of many signals that adopting it in the core may be worth it.</div><div><br></div><div>At the same time, I understand that the OTP team may not want the additional maintenance workload.</div><div><br></div><div>Thomas Depierre<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, 9 May 2021 at 12:25, Peer Stritzinger <<a href="mailto:peer@stritzinger.com" target="_blank">peer@stritzinger.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I generally agree with that: it would be cool to have the subset of gproc that is process registry in OTP (its kind of a Swiss army knife with lots of other stuff in there too).<br>
<br>
OTOH: gproc is around so long and stable that it could be considered canon.  So probably there is no pressure to replace it since I assume many pragmatic devs are just adding gproc to their dependencies as soon as they need a term - process registry.<br>
<br>
It has gproc:i() which is a replacement for shell command i() listing all processes with their registered names.<br>
<br>
All that’s missing is a optional functionality for observer to also look into gproc.<br>
<br>
Or actually probably something more generic: a way similar go {via, M, N} argument for the gen_* behaviours.  A way to “register” other process registries.  All they need is a way to export a function that translates from pid -> name(s)<br>
<br>
This can then work with the new pg (didn’t check if that’s already supported by observer).<br>
<br>
BTW: the initial question was about “non unique” process registry:  that’s what the new pg is.  You can register multiple processes with a term that is then called the name of the group of processes (just another way of saying non unique).<br>
<br>
Now back to the gproc vs. built in:  with pg having taken over yet another part of gprocs functionality (non unique names) maybe it ist actually time for a built in registry for local unique term registration.<br>
<br>
It probably doesn’t fit well into pg because a.) the name of the module containing the g for “group” and b.) pg is for distributed use cases and in this case uniqueness can be quite bothersome because all solutions for global uniqueness get in the way of scalability and we don’t want to go back to the days where global needing a fully connected connection graph is limiting scalability Well global is still there and gives you unique names across Erlang distribution if you are willing to work with a fully connected mesh.  BTW it also works locally.<br>
<br>
So current offers in OTP:<br>
<br>
Erlang:register() - built into BEAM, focus on being as fast as possible, unique name which needs to be a atom<br>
<br>
global: global distributed unique names and locks, maintains fully connected mesh, terms can be names<br>
global_groups:  adds namespaces to global for better scalability<br>
<br>
pg:  process groups, non unique names, terms can be names, distributed solution which a notion of scalability.  <br>
<br>
(There is also pg2 which is deprecated)<br>
<br>
The only thing missing is unique local names that can be terms.<br>
<br>
Cheers,<br>
-- Peer <br>
<br>
> On 7. May 2021, at 09:46, Nicolas Martyanoff <<a href="mailto:khaelin@gmail.com" target="_blank">khaelin@gmail.com</a>> wrote:<br>
> <br>
> Kenneth Lundin <<a href="mailto:kenneth.lundin@gmail.com" target="_blank">kenneth.lundin@gmail.com</a>> writes:<br>
> <br>
>> Take a look at <a href="https://github.com/uwiger/gproc" rel="noreferrer" target="_blank">https://github.com/uwiger/gproc</a>, it seems to be a good fit<br>
>> for your requirements.<br>
> Gproc is interesting, but the point of having useful features in OTP is<br>
> both to make sure they stay coherent and aligned on the Erlang/OTP<br>
> vision, and to avoid having to depend on external libraries which may or<br>
> may not be maintained for something as fundamental as process<br>
> identification.<br>
> <br>
> -- <br>
> Nicolas Martyanoff<br>
> <a href="http://snowsyn.net" rel="noreferrer" target="_blank">http://snowsyn.net</a><br>
> <a href="mailto:khaelin@gmail.com" target="_blank">khaelin@gmail.com</a><br>
<br>
</blockquote></div>
</blockquote></div>