Support for non-unique process labels?

[Stanislav Ledenev]

>>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.

Those claims without evidence look like manipulation.
And how does a library for processes dictionaries look up is connected with
the theme of this topic?

вс, 9 мая 2021 г. в 16:32, Thomas Depierre <depierre.thomas@REDACTED>:

> 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/a1d59e78/attachment.htm>