FJP.CommonPool and VM shutdown (original) (raw)

Doug Lea dl at cs.oswego.edu
Wed Jan 2 06:53:34 PST 2013

On 01/01/13 13:20, Brian Goetz wrote:

I can't get too worked up about this failure mode, so I'll revert to bikeshed mode: a nicer name would have "await" in the name.

I made a small adjustment to make these more consistent. While awaitTermination and awaitQuiescence remain unchanged from version I pasted, and have the same form of requiring a timeout argument, the untimed version is now only available in its previous form of ForkJoinTask.helpQuiesce. The implementation just so happens to relay to awaitQuiescence without a timeout. Even though they are basically the same, the usage contexts differ enough to separate them in this way.

Minor updates to javadocs at: http://gee.cs.oswego.edu/dl/jsr166/dist/docs/java/util/concurrent/ForkJoinPool.html

(Currently, awaitQuiescence never actually blocks but only tries helping until quiescent. There are a few cases where you might want it to block, as when the last ongoing task before quiescence is itself blocking. It is (barely) possible to trap/detect this, so this might change someday.)

-Doug

On 1/1/2013 6:55 AM, Doug Lea wrote:

While writing some CompletableFuture test code, I realized that there's a potential unhappy surprise lurking in code of the form: class X { public static void main(String[] args) { new ComputationUsingCommonPool(...).fork(); } }

Because the common pool uses daemon threads, it is OK for the VM to shutdown immediately after the fork().

More information about the lambda-libs-spec-observers mailing list