posting to a shutdown thread pool?

[jrochkind]

If you post to a threadpool that is in shutdown? state, your work does not get executed and the call returns false.

What I would have expected instead, is following whatever is the pool's overflow_policy -- raise an exception for :abort, run in caller thread for :caller_runs, and only return without complaining (maybe returning false, sure) for :discard.

But is the present behavior what the java.util.concurrent stuff does? Maybe they have some reason for it, I guess, and I understand wanting to stay consistent. But following the overflow_policy seems more useful and expected to me.

It is surprising to me to have to check the return value of #post to know if the work is actually going to be done, I'd expect an RejectedExcecution exception by default if posting to a shutdown pool (and since overflow_policy is abort by default, that's what I'd get if it followed overflow policy)

[jrochkind]

Looks to me like Java thread pools do what I'm suggesting -- they use the overflow policy for work submitted to a shut down pool too.

See "Rejected tasks" at:

https://docs.oracle.com/javase/7/docs/api/java/util/concurrent/ThreadPoolExecutor.html

New tasks submitted in method execute(java.lang.Runnable) will be rejected when the Executor has been shut down, and also when the Executor uses finite bounds for both maximum threads and work queue capacity, and is saturated. In either case, the execute method invokes the RejectedExecutionHandler.rejectedExecution(java.lang.Runnable, java.util.concurrent.ThreadPoolExecutor) method of its RejectedExecutionHandler. Four predefined handler policies are provided…

[jdantonio]

Nice catch. Thank you. The overflow policies are a recent addition. The current post-shutdown behavior was written first. The behavior you suggest makes more sense now that we have the overflow policies, consistency with Java's thread pools has always been a goal (Sun/Oracle has some very smart people working on this stuff). We'll make this change in the next release.

[jrochkind]

Oh awesome, looks like I discovered this gem right at the point when you had added enough for me to use it, I didn't realize the overflow policies were a recent addition! Awesome.

[jdantonio]

This behavior has been implemented for pure-Ruby thread pools, but still needs implemented for the JRuby-optimized thread pools.

[jrochkind]

Awesome. I'm surprised the JRuby optimized thread pools don't already do it if they are using java.util.concurrent.ThreadExecutor under the hood which does it itself.

But if it would be helpful for me to try and help, I can try to find time to take a look and make a PR? Did you already add tests for this behavior that run against the pure-ruby version, and can be run against the Java version too to confirm? Or would be that be the place to start? Do you guys already have a test infrastructure that tests everything against multiple environments to ensure consistent behavior?

[jdantonio]

@jrochkind The JRuby thread pools are just a thin wrapper over java.util.concurrent and those thread pools reject tasks post when the pool isn't running. @rkday has submit PR #201 which makes the corresponding update to the Java thread pools. I expect to merge that PR today.

[jdantonio]

Completed in PRs #199, #201, and #202.