We have a process that wants to start the work, and the process that does the work. With jobs these two are actually the same. The queue process is a coordinator which accept requests and issues grants per some rule (e.g. max n at the same time, or max n per some unit of time). The client process (e.g. plug request handler) asks the queue for permission. After the permission is granted, the client proceeds, and after it’s done the client informs the queue. No other extra worker processes need to be started.
As a result, there might be more processes started in the system (such as plug/phoenix request handlers), but most of them will wait until the queue process gives them permission to proceed.
In addition, the latency of one job might be affected by the latency of previous unrelated jobs that were running in the same worker.
Sounds good to me. However, currently if max_children is exceeded, start_child returns an error. So not sure how the API would look like for buffering.
Either way, I did once or twice with Parent.GenServer which is basically supervisor as a GenServer. The basic idea was to start a child when requested, unless max children are running, in which case we buffer the request. Once a child stops, we take the next req from the buffer and start the new child.
As long as the worker processes don’t change the GenServer state on each request, this sounds like a scenario for jobs to me.
I find it’s a very complex behaviour, and it definitely wouldn’t be my first choice in this scenario.
