[erlang-questions] Supervision question
Mon Nov 30 22:58:57 CET 2015
If I'm reading this correctly, your worker_sup will be restarted after the
max_restarts is reached for the poolboy pool. This means that the caller
can link or monitor worker_sup, correct? Or do you need a one_for_all
I have a suspicion dependencies (link/monitor) and discovery (gproc,
registered names) are also being confused or conflated in your question.
On Mon, Nov 30, 2015 at 3:25 PM, David Leach <dleach@REDACTED> wrote:
> Hi All,
> We have an application that starts pools of different kinds of workers and
> we want to offer the caller the ability to "link" to a pool of workers.
> We're using poolboy to manage the pools and gproc for naming the pools and
> ensuring startup is complete before returning a reference to the caller. We
> don't want to link to poolboy, because it can and should be restarted by
> the supervisor supervising it. The behavior we want is, if the supervisor
> managing poolboy reaches its maximum restarts the caller who is linked
> also dies. We also want that pool to disappear if the caller dies and the
> caller can restart it again. Structure looks a little like this:
> super_sup -> worker_sup ->
> Right now, the caller is linked to the worker_sup so that if the
> worker_sup goes down caller also goes down. The pool_manager monitors the
> caller and sends exit(WorkerSupPid, shutdown) if the caller goes down so
> that the pool gets cleaned up.
> Is there a better way of doing this? Better being easier for someone
> reading the code to understand quickly or more reliably if there is a
> problem with this implementation?
> We thought about having the super_sup start two children, one of
> them performing the role of the pool_manager in this situation . But that
> seems a bit excessive, and how might one name it clearly to differentiate
> the roles of the pool_manager and it. The pool manager takes care of
> details of the pool and translates the reference the caller has to a pid.
> Thanks in Advance,
> erlang-questions mailing list
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the erlang-questions