[erlang-questions] Request for opinions on using process dictionary for meta information

[Gianfranco Alongi]

Hi!

It kind of sounds similar to the idea behind gproc, which is a widely used
library,
so as everyone has said already - this is perfectly fine.

https://github.com/uwiger/gproc

Use case: System inspection

Gproc was designed to work as a central index for "process metadata", i.e.
properties that describe the role and characteristics of each process.
Having a single registry that is flexible enough to hold important types of
property makes it easier to (a) find processes of a certain type, and (b)
query and browse key data in a running system.

On Tue, Apr 18, 2017 at 11:33 AM, Mikael Pettersson <mikpelinux@REDACTED>
wrote:

> Jay Doane writes:
>  > Our team is currently using the process dictionary to store meta
>  > information for long running processes, and would like to hear from
> folks
>  > familiar with beam internals whether this is a recommended practice.
>  >
>  > Essentially we add meta information about the current request in a
> process
>  > dictionary of every process related to handling of this request. This
>  > information could be:
>  > - current file
>  > - user name of initiator of the request
>  > - http query parameters
>  > - type of a process (indexer | compactor | http_handler)
>  >
>  > For example, when we detect performance problems, we run a function that
>  > returns the Pids of (say) top memory using processes. We use the meta
> info
>  > stored in process dictionaries to determine which documents are using
>  > excessive memory so we can take corrective action.
>  >
>  > In practice, we are unable to use normal OTP messaging because in many
>  > cases, the high memory using processes have also grown huge message
> queues,
>  > and so would be unresponsive to any additional messages.
>  >
>  > Given our existing constraints, is this a reasonable use of the process
>  > dictionary?
>
> Yes, I think this is perfectly reasonable.
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20170418/25e99db8/attachment.htm>