I’ve done some digging in the poolboy source and it appears the child_spec function forces the type to
- Is there some way around that other than writing the child_spec myself manually?
- Is there something bad that would happen if poolboy were managing supervisors instead of workers?
Could you please share why you want poolboy to manage supervisors dynamically ?
supervisor in the child spec is mostly about how much time is given for the process to shut itself down.
I haven’t seen it being mentioned in the docs, but maybe there is something in the source code for the supervisor behaviour.
But that only makes a difference if the
shutdown is not provided in the child spec.
Also worker/supervisor processes seem to be counted differently (when calling
count_children), but that probably doesn’t have huge runtime implications.
A library that I’m using generates connections that are supervisors of a couple processes necessary to maintain the connection. It technically maintains the actual connection as a child to the supervisor, but every function that you pass a process to, it expects you to pass the supervisor. Thus, I’m interested in maintaining a pool of the connection’s supervisor.
Thanks, I was more curious if there would be some reason that poolboy would care specifically. I’ll probably trudge ahead anyways, since I can write the child spec myself. I’ll probably create an issue with poolboy and this’ll be an enhancement or they’ll tell me it’s a bad idea.
As far as Erlang goes, some of the things that could be affected were addressed in the last question I asked. What happens if you supervise a supervisor as a worker?
There is a post by @rvirding regarding this in the forum. The
supervisor distinction affects restart and how a process is killed.
I would likely roll my own process pooler. It is perhaps the most rewritten piece of Erlang application out there because not all situations fit poolboy.