Support for non-unique process labels?

[Thomas Depierre]

 It may be worth pointing out that Elixir rolled out a Registry in their
stdlib that does it because well it needed it.
https://hexdocs.pm/elixir/Registry.html

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.

At the same time, I understand that the OTP team may not want the
additional maintenance workload.

Thomas Depierre

On Sun, 9 May 2021 at 12:25, Peer Stritzinger <peer@REDACTED> wrote:

> 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).
>
> 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.
>
> It has gproc:i() which is a replacement for shell command i() listing all
> processes with their registered names.
>
> All that’s missing is a optional functionality for observer to also look
> into gproc.
>
> 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)
>
> This can then work with the new pg (didn’t check if that’s already
> supported by observer).
>
> 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).
>
> 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.
>
> 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.
>
> So current offers in OTP:
>
> Erlang:register() - built into BEAM, focus on being as fast as possible,
> unique name which needs to be a atom
>
> global: global distributed unique names and locks, maintains fully
> connected mesh, terms can be names
> global_groups:  adds namespaces to global for better scalability
>
> pg:  process groups, non unique names, terms can be names, distributed
> solution which a notion of scalability.
>
> (There is also pg2 which is deprecated)
>
> The only thing missing is unique local names that can be terms.
>
> Cheers,
> -- Peer
>
> > On 7. May 2021, at 09:46, Nicolas Martyanoff <khaelin@REDACTED> wrote:
> >
> > Kenneth Lundin <kenneth.lundin@REDACTED> writes:
> >
> >> Take a look at https://github.com/uwiger/gproc, it seems to be a good
> fit
> >> for your requirements.
> > Gproc is interesting, but the point of having useful features in OTP is
> > both to make sure they stay coherent and aligned on the Erlang/OTP
> > vision, and to avoid having to depend on external libraries which may or
> > may not be maintained for something as fundamental as process
> > identification.
> >
> > --
> > Nicolas Martyanoff
> > http://snowsyn.net
> > khaelin@REDACTED
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20210509/db6f1729/attachment.htm>