<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Sat, May 14, 2016 at 3:28 AM Loïc Hoguin <<a href="mailto:essen@ninenines.eu">essen@ninenines.eu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The primary function of supervisors is to provide a hierarchy of<br>
processes belonging to an application. With such a hierarchy it becomes<br>
possible to find and query information about any single process in your<br>
system in a standard manner.<br><br></blockquote><div>I'm rather interested in this aspect of supervised processes. Especially in the case of a simple_one_for_one supervisor, it's unlikely that the supervised processes will be registered, and it's possible that there could be a rather large number of them--maybe in the tens or hundreds of thousands, depending on the use case. <span style="line-height:1.5">I'm curious how others deal with finding a specific temporary process if, for instance, you want to check on the progress of the work it's doing.</span></div><div><span style="line-height:1.5"><br></span></div><div><span style="line-height:1.5">My current solution is to have a locally registered "manager" process as a supervised sibling to the SOFO worker supervisor, and the manager just has a dict that maps UUIDs to worker PIDs. I.e. creating a "worker" process entails both a supervisor:start_child() call and storing the worker id -> pid mapping in the manager. Is this a typical way to handle temporary workers?</span></div></div></div>