Thread pools behaving oddly with `max_queue` and `remaining_capacity`

We're in need for a thread pool that has a maximum number of parallel threads, no queue and fails if too many threads are added. We also need to be able to detect how many threads are "free" at a given time.

We've tried almost all of the ThreadPool and ThreadPoolExecutor classes but can't get it to work:

require 'concurrent'

pool = Concurrent::ThreadPoolExecutor.new(
  min_threads: 0,
  max_threads: 5,
  max_queue: 0,
  fallback_policy: :abort,
  auto_terminate: false
)

6.times do
  pool.post { sleep 5 }
  puts pool.remaining_capacity
end

pool.wait_for_termination

If we interpret the documentation right, this should create a thread pool with 0 threads at start that can grow up to 5 threads which are handled in parallel. If all 5 threads are occupied, posting new work units should result in an exception. There should be no additional queue. We'd also expect remaining_capacity to drop by 1 each time something has been posted and the previous threads are still busy.

The output of the above script:

-1
-1
-1
-1
-1
-1

Expected would be:

4
3
2
1
0
=> EXCEPTION

Did we interpret the documentation wrong and how can we achieve what we need? We're also need to be able to detect the number of idle threads so that we can post the right number of work units to it.

On a side-note: The above example stops with a number of exceptions like the following:

/usr/local/lib/ruby/gems/2.4.0/gems/concurrent-ruby-1.0.5/lib/concurrent/synchronization/mri_lockable_object.rb:43:in `sleep': No live threads left. Deadlock? (fatal)
6 threads, 6 sleeps current:0x00007fa6936e27d0 main thread:0x00007fa6937044c0
* #<Thread:0x00007fa69487f0b8 sleep_forever>
   rb_thread_t:0x00007fa6937044c0 native:0x00007fff7b53e000 int:1
   /usr/local/lib/ruby/gems/2.4.0/gems/concurrent-ruby-1.0.5/lib/concurrent/synchronization/mri_lockable_object.rb:43:in `sleep'
   /usr/local/lib/ruby/gems/2.4.0/gems/concurrent-ruby-1.0.5/lib/concurrent/synchronization/mri_lockable_object.rb:43:in `wait'
   /usr/local/lib/ruby/gems/2.4.0/gems/concurrent-ruby-1.0.5/lib/concurrent/synchronization/mri_lockable_object.rb:43:in `ns_wait'
   /usr/local/lib/ruby/gems/2.4.0/gems/concurrent-ruby-1.0.5/lib/concurrent/synchronization/abstract_lockable_object.rb:43:in `ns_wait_until'
   /usr/local/lib/ruby/gems/2.4.0/gems/concurrent-ruby-1.0.5/lib/concurrent/atomic/event.rb:87:in `block in wait'
   /usr/local/lib/ruby/gems/2.4.0/gems/concurrent-ruby-1.0.5/lib/concurrent/synchronization/mri_lockable_object.rb:38:in `block in synchronize'
   /usr/local/lib/ruby/gems/2.4.0/gems/concurrent-ruby-1.0.5/lib/concurrent/synchronization/mri_lockable_object.rb:38:in `synchronize'
   /usr/local/lib/ruby/gems/2.4.0/gems/concurrent-ruby-1.0.5/lib/concurrent/synchronization/mri_lockable_object.rb:38:in `synchronize'
   /usr/local/lib/ruby/gems/2.4.0/gems/concurrent-ruby-1.0.5/lib/concurrent/atomic/event.rb:84:in `wait'
   /usr/local/lib/ruby/gems/2.4.0/gems/concurrent-ruby-1.0.5/lib/concurrent/executor/ruby_executor_service.rb:49:in `wait_for_termination'
   concurrent_test.rb:16:in `<main>'

I have currently no idea what this is about. But this second problem does not happen in our application and is not a dealbreaker.

Thanks a bunch for having a look at the first question though - this would help us a lot. Keep up your wonderful work!

• Operating system: mac
• concurrent-ruby version: 1.0.5
• concurrent-ruby-ext installed: no
• concurrent-ruby-edge used: no

Start with the ThreadPoolExecutor configuration and the reported entry point in lib/concurrent/executor/ruby_executor_service.rb, then inspect the synchronization paths in lib/concurrent/synchronization/mri_lockable_object.rb and related executor code. Reproduce the script and compare max_queue, remaining_capacity, rejection, and wait_for_termination behavior with the documented expectations; done means the intended behavior is established and covered by an appropriate test or documentation update.