Support for non-unique process labels?

Stanislav Ledenev s.ledenev@REDACTED
Fri May 7 11:03:11 CEST 2021


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 <essen@REDACTED>:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20210507/281384e0/attachment.htm>


More information about the erlang-questions mailing list