<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 18 April 2017 at 10:29, Gianfranco Alongi <span dir="ltr"><<a href="mailto:gianfranco.alongi@gmail.com" target="_blank">gianfranco.alongi@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi!<div><br></div><div>It kind of sounds similar to the idea behind gproc, which is a widely used library,<br>so as everyone has said already - this is perfectly fine.</div><div><br></div><div><a href="https://github.com/uwiger/gproc" target="_blank">https://github.com/uwiger/<wbr>gproc</a></div></div></blockquote><div><br></div><div>Doesn't gproc store the process metadata in an ETS table? That's a valid approach, too, but you need a monitor process to clean up if the process dies.</div><div>As another pro-example of storing information in the process dictionary; this is what lager does with metadata -- see lager:md.</div><div><br></div><div>Both approaches are valid: we use all of the following:</div><div><br></div><div>1. Process dictionary (usually for lager, but sometimes separately).</div><div>2. Separate process registry using one or more ETS tables (we don't use gproc; we wanted slightly different semantics).</div><div>3. Process responds to gen_server:call(Pid, info)</div><div><br></div><div>They're useful for different information, for different scenarios.</div><div><br></div><div>I'd be reluctant to use the process dictionary for anything other than process-internal-use or debugging information, though.</div></div></div></div>