Re: Support for non-unique process labels?

Nathan Long <[email protected]>
Newsgroups gmane.comp.lang.erlang.general
Message-ID <CAOyE-6b3K8UN9iVD68D3LnrJZhdc6z9pQ0OFskBJ6TyzdpRO0w@mail.gmail.com>
In my original example, the "db_connection" processes are created by a
library. Ideally any solution to this problem would be something
standardized so that library authors can use it and their users don't have
to do anything special to see the labels.

A global name like "db_connection_(UUID)" would work, but is a hack, since
all we really want is to say what sort of process this is.

On Fri, May 7, 2021 at 7:54 AM Loïc Hoguin <[email protected]> wrote:

> I don't know what makes you think that. What I linked to does not
> eliminate global atoms like we have today, it just adds local atoms
> which are GC. Global atoms still go into the atom table and are never
> GC. They are the atoms used for modules, functions and literals in the
> code. Local atoms would only be used when generating atoms. The
> performance cost would certainly not be devastating.
>
> On 07/05/2021 11:03, Stanislav Ledenev wrote:
> > As far as I understand how VM works implementation of the idea of
> > garbage collectable atoms will lead to devastating consequences. And
> > performance will be the first victim.
> >
> > IMHO cheapest implementation of process labels can be achieved on top of
> > process dictionary (oh, slippery) through some special value. Plus
> > modification of observer app.
> >
> > пт, 7 мая 2021 г. в 11:24, Loïc Hoguin <[email protected]
> > <mailto:[email protected]>>:
> >
> >     What you want is to be able to either:
> >
> >     * register processes using any term and not just atoms
> >     * have garbage collectable atoms
> >
> >     That way Observer will always show the proper name.
> >
> >     Then for logs all you need is for <0.2555.0> to be identified at some
> >     point (in other logs with its registered name + pid for example). Or
> >     hook into logger as others have pointed out.
> >
> >     GC atoms has long been on the wishlist of many people:
> >
> >     * https://www.erlang.org/erlang-enhancement-proposals/eep-0020.html
> >     *
> >
> https://github.com/nox/otp/commit/bf3334c1d2c0e404abaec72a985134def158afcf
> >
> >     It would be fantastic if this could get traction.
> >
> >     Cheers,
> >
> >     On 06/05/2021 16:06, Nathan Long wrote:
> >      > Is there a way to add a non-unique label to a process? If not, I
> >     would
> >      > like to propose that it be added.
> >      >
> >      > The label could be shown with or instead of a PID. I think this
> >     would be
> >      > useful in at least two areas.
> >      >
> >      > First, when observing a running system, the PID is not
> >     descriptive. I
> >      > have Observer open right now looking at part of my system, and I
> >     can see
> >      > one globally registered process name displayed, but everything
> >     else is a
> >      > PID. What are those processes? I might be able to figure it out by
> >      > clicking the process and seeing what its initial call was, but
> >     often I
> >      > can tell is "it's a GenServer." The structure of the system would
> be
> >      > much more apparent if I saw labels like "db_connection" or
> >      > "request_queue_worker".
> >      >
> >      > Second, when reading error messages in logs or an exception
> >     tracker, the
> >      > PID is not useful. For example, I'm looking at an error in Sentry
> >     right
> >      > now that says "Sentry.CrashError error ** (exit) 'stopping because
> >      > dependent process <0.2255.0> died: killed'". I have no idea what
> >      > `<0.2555.0>` was, so I don't know what to debug.
> >      >
> >      > Does this exist or would others support it being added to the
> BEAM?
> >      >
> >      > -- Nathan
> >
> >     --
> >     Loïc Hoguin
> >     https://ninenines.eu
> >
>
> --
> Loïc Hoguin
> https://ninenines.eu
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.