JavaThreadPoolExecutor have bounded queue for min_threads = 0

[obrok]

In JavaThreadPoolExecutor there is this:

if min_length == 0 && @max_queue == 0
  queue = java.util.concurrent.SynchronousQueue.new

It has the surprising result that Concurrent::ThreadPoolExecutor.new(max_threads: 4) has a bounded queue while Concurrent::ThreadPoolExecutor.new(max_threads: 4, min_threads: 1) an unbounded one. What is the reason for this condition? Maybe there should be a separate option for this?

[jdantonio]

@obrok I'll have to take a closer look once I get home from work, but I don't think that is correct. In both cases the @max_queue value is set to 0 because of DEFAULT_MAX_QUEUE_SIZE = 0 and in both cases the Java queue is created without a limit.

The reason for the one case where the internal queue is a java.util.concurrent.SynchronousQueue is because that is the default behavior for java.util.concurrent.ThreadPoolExecutor.

A bit of background:

When I created the current thread pools I started with the Java pools. The intent was to build a Ruby wrapper for Java's thread pools, define that behavior, then build Ruby thread pools with the exact same behavior. I created a bunch of java.util.concurrent.ThreadPoolExecutor, java.util.concurrent.FixedThreadPool, and java.util.concurrent.CachedThreadPool instances in JIRB using various parameters then interrogated them to see what Java was creating. I then wrote a bunch of passing RSpec tests that served as an executable specification of Java's thread pools. I then built the Ruby thread pools following red/green/refactor using those RSpec tests.

The logic in our code that you reference mapped to the behavior of Java's fixed and cached thread pools and was written based on what I discovered when I interrogated all those objects in JIRB.

[obrok]

It seems to me like this is meant to allow for the creation of an executor with no queuing allowed, which makes sense, but triggering that when min_threads is 0 is a bit odd.

[jdantonio]

@obrok I apologize for having lost track of this. I've been doing a lot of traveling lately. That's over and I should have more time over the next few months to work on this gem.

The intent is for the :max_queue option to declare an unbound queue when set to zero. This is the behavior of Java's thread pools.

[obrok]

But that will just happen without the extra condition I think? The code in question seems to handle a case where you want to create an executor with an actual 0 maximum queue length instead of an unbounded one, but maybe that should be a separate executor or a separate option? I'm sorry if I'm repeating myself, but I also sort of lost track of this issue :)