[erlang-questions] simple_one_for_one supervisor - what happens at restart? (also: gen_tcp)

Ryan Stewart <>
Sat May 14 19:24:03 CEST 2016


Oliver, gproc looks exactly right; thanks for the pointer! I just didn't
know about it, so essentially I was building my own with very limited
features. Pardon my ignorance. I've been working in Erlang for a little
over 2 years, and I only just feel like I have a handle on how everything
fits together. I still don't know what all libraries are out there to do
common jobs.

Hmm, that seems like a good subject for a fresh thread...

On Sat, May 14, 2016 at 12:16 PM Oliver Korpilla <>
wrote:

> Hello, Ryan.
>
> Isn't this normally the job of a registry like gproc or am I
> misunderstanding your requirements?
>
> I usually start the worker dynamically through the supervisor and let it
> do its own registration.
>
> Cheers,
> Oliver
>
>
> Gesendet: Samstag, 14. Mai 2016 um 18:57 Uhr
> Von: "Ryan Stewart" <>
> An: "Loïc Hoguin" <>, Chandru <
> >
> Cc: "Erlang-Questions Questions" <>
> Betreff: Re: [erlang-questions] simple_one_for_one supervisor - what
> happens at restart? (also: gen_tcp)
>
> On Sat, May 14, 2016 at 3:28 AM Loïc Hoguin <>
> wrote:The primary function of supervisors is to provide a hierarchy of
> processes belonging to an application. With such a hierarchy it becomes
> possible to find and query information about any single process in your
> system in a standard manner.
>
> 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. 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.
>
> 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?_______________________________________________ erlang-questions
> mailing list 
> http://erlang.org/mailman/listinfo/erlang-questions[http://erlang.org/mailman/listinfo/erlang-questions]
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20160514/84730c85/attachment.html>


More information about the erlang-questions mailing list