Non-unique process names in observer

Roger Lipscombe <[email protected]>
Newsgroups gmane.comp.lang.erlang.general
Message-ID <CAJgnQd_FRe3W38PJ+2b20hWQ059TAPOg46jkjqCVND2TOLM3SA@mail.gmail.com>
In Erlang, a process can have a registered name, but it must be unique
and must be an atom.

In the http://erlang.org/pipermail/erlang-questions/2021-May/100972.html
thread, it was suggested that processes should have non-unique names
associated with them, making debugging easier.

Lukas pointed out that adding more information to the PID term was a
lot of work, but suggested extending proc_lib to add further metadata
that could be displayed by observer.

This morning, using observer, I found myself looking at a large
supervision tree with nothing but PIDs.

So I did some digging around to see what might be involved. If I get
time (I probably won't), I might put together a PR, but this'll be
useful for anyone else thinking about implementing it.

Observer gets the display name for its processes here:
https://github.com/erlang/otp/blob/OTP-24.0.2/lib/runtime_tools/src/appmon_info.erl#L708-L714;
it'd be relatively simple to get the process dictionary and look up
'$process_label' (better naming suggestions are welcome).

Adding that functionality to proc_lib, on the other hand... Well.

proc_lib offers *21* different ways to start a process, and only
spawn_opt/{2,3,4,5} allows specifying extra options, which is where
you'd probably want to put that label. I'm uncomfortable with adding
it to the spawn_option() type.

For OTP's built-in behaviours, you'd need to define an extra option to
be passed to gen_server:start_link, gen_statem:start_link, etc. That
would be less complicated (because they already take options), but is
still a chunk of work.

In the short term, I think the easiest option might be to make the
changes to observer, document it appropriately, and then just
encourage library authors to put('$process_label', MyLabel) wherever
it seems sensible.

Thoughts?

Cheers,
Roger.
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.