I think worker / 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.
There is a post by @rvirding regarding this in the forum. The worker / 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.