mirror of
https://github.com/puma/puma.git
synced 2022-11-09 13:48:40 -05:00
3896e2aa12
Rapidly adding work to the ThreadPool can result in many jobs making it onto `@todo` before one of the jobs gets the mutex lock to decrement `@waiting`. So `@waiting == 0` isn't true and no thread is spawned even though there's work piling up, e.g.:
```ruby
require 'puma/thread_pool'
pool = Puma::ThreadPool.new(1, 3) { sleep 2 }
3.times { pool << 1 }
sleep 1
pool.spawned #=> 1 # When 3 is expected
```
Checking if `@waiting < @todo.size` shows that there's more work to do than threads waiting even if `@waiting` hasn't been decremented to `0` and also covers the base case where `@waiting == 0` and `@tudo.size == 1`.
An alternate option would be just adding the new check without removing the old one, something like `(@waiting == 0 or @waiting < @todo.size)`, but I don't think it's necessary unless for some kind of performance reason.
|
||
|---|---|---|
| .. | ||
| app | ||
| accept_nonblock.rb | ||
| binder.rb | ||
| capistrano.rb | ||
| cli.rb | ||
| client.rb | ||
| cluster.rb | ||
| compat.rb | ||
| configuration.rb | ||
| const.rb | ||
| control_cli.rb | ||
| daemon_ext.rb | ||
| delegation.rb | ||
| detect.rb | ||
| events.rb | ||
| io_buffer.rb | ||
| java_io_buffer.rb | ||
| jruby_restart.rb | ||
| minissl.rb | ||
| null_io.rb | ||
| rack_default.rb | ||
| rack_patch.rb | ||
| reactor.rb | ||
| runner.rb | ||
| server.rb | ||
| single.rb | ||
| tcp_logger.rb | ||
| thread_pool.rb | ||
| util.rb | ||