class Puma::ThreadPool

makes it through the reactor and can then be processed by the thread pool.
by the server. This would continue until a fully buffered request
method would not block and another request would be added into the reactor
to try to buffer the request. In that scenario the next call to this
then the `@todo` array would stay the same size as the reactor works
For example if a slow client has only sent a header, but not a body
request, it might not be added to the `@todo` array right away.
It's important to note that even though the server might accept another

signaled, usually this indicates that a request has been processed.
pause here, and wait until the `not_full` condition variable is
If there are 5 threads and all 5 of them are busy, then it will

can pull a request right away.
requests, this method will not wait and the `Puma::Server`
For example: if there are 5 threads, but only 4 working on

worker can pick it up and process it.
spare capacity, then the request can be left on the socket so the other
number of requests then it is at capacity. If another Puma process has
number of requests at the same time. If it is already processing that
The general idea is that the thread pool can only work on a fixed

pass to the reactor.
the thread pool can pull more requests from the socket and
This method is used by `Puma::Server` to let the server know when

def wait_until_not_full
  with_mutex do
    while true
      return if @shutdown
      # If we can still spin up new threads and there
      # is work queued that cannot be handled by waiting
      # threads, then accept more work until we would
      # spin up the max number of threads.
      return if busy_threads < @max
      @not_full.wait @mutex
    end
  end
end