[erlang-questions] Supervisors as factories *and* registries

[Mark Fine]

Probably everyone's done this at least once, but I played around with
redoing supervisor.erl to provide a which_child() API and to remove
restrictions on dynamically adding various types of children --
http://github.com/mfine/manager.

On Mon, Mar 22, 2010 at 9:34 AM, Garrett Smith <g@REDACTED> wrote:
> I've gotten into the habit of using supervisors as factories and
> really like the pattern. I think it's clean to delegate process life
> cycle to supervisors, since that's what they're there for. So far so
> good, with one big exception...
>
> As factories, supervisors are also a logical candidate as registries.
> supervisor:which_children, for example, is a brute force way to get at
> the processes under supervision.
>
> Bit I need a finer grained interface to supervised children. I wish
> supervisors exposed state the way gen_server does, in which case I
> could maintain an index (for example) that would let me access
> children more efficiently. (This seems like a conspicuously missing
> feature, but there's probably a good reason for it.)
>
> Is there a recommended pattern for this sort of thing? To summarize
> what I'm looking for:
>
> - Wrap calls to supervisor:start_child in a factory function for processes
> - Provide a lookup interface to supervised children that doesn't rely
> on a linear scan of supervisor:which_children(Sup)
>
> I could obviously maintain a separate process as a registry, but I'd
> prefer to avoid the sync/link/cleanup overhead associated with that.
> I'd be okay with hacking supervisor (create a supervisor2?), but I
> haven't explored that option.
>
> Garrett
>
> ________________________________________________________________
> erlang-questions (at) erlang.org mailing list.
> See http://www.erlang.org/faq.html
> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED
>
>