Support for non-unique process labels?
Fri May 7 13:54:39 CEST 2021
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 <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
> It would be fantastic if this could get traction.
> 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
> > 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
> > 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
More information about the erlang-questions