Support for non-unique process labels?

Lukas Larsson lukas@REDACTED
Fri May 7 08:41:28 CEST 2021


On Thu, May 6, 2021 at 6:55 PM Nathan Long <him@REDACTED> 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".

Adding something like this would be relatively simple as it could just use
the same mechanism as when observer gets the "initial call", that is
something is put in the process dictionary of that process that observer
can fetch. Today the "initial call" is manager by proc_lib:

I would not be against extending proc_lib to allow setting additional
metadata that be fetched by observer.

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.

When a process dies, all of the data about that process is deleted, the
only thing that remains is the PID. So in order to print anything useful
the label would have to be part of the PID term. This is doable, though it
would make the PID term about 4 times as large and make comparison a bit
slower. Also since it would have to work with distribution, it would
require extensions to the External Term Format together with capability
flags etc etc, in other words, a lot of work writing C code.

Another way would be to store all of the PIDs that you are interested in
somewhere and then create a logger formatter that processes all of the
strings being emitted by logging and look for the PID that you want to
replace with a more meaningful name. I suppose that observer could be
extended to fetch information from this source as well when displaying

I would prefer the second solution here as that would be something that
could be done by any library. If the feature becomes popular, we can check
and see if we can create a more performant solution later.

> Does this exist or would others support it being added to the BEAM?

> -- Nathan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the erlang-questions mailing list