[erlang-questions] Request for opinions on using process dictionary for meta information
Tue Apr 18 11:29:25 CEST 2017
It kind of sounds similar to the idea behind gproc, which is a widely used
so as everyone has said already - this is perfectly fine.
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 <>
> 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
> > familiar with beam internals whether this is a recommended practice.
> > Essentially we add meta information about the current request in a
> > 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
> > 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
> > 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the erlang-questions