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

Brian Goetz brian.goetz at oracle.com
Tue Jan 1 08:42:20 PST 2013

OK, let me make sure I have this straight.

You used to only be able to call fork from a pool thread. To get to a pool thread, you had to do pool.invoke, which means a likely-non-daemon thread is waiting for the result.

Now, someone can call invoke/fork from a non-pool thread, at which point it becomes temporarily coopted to be a limited pool thread.

What if, when calling invoke from a non-pool-thread, we set a threadlocal that says "I am a temporary pool thread". Forks from non-pool-threads would only be allowed if they are acting as temporary pool threads?

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(). This is not at all a common usage: normally you'd use invoke() or some other construction that somehow uses the computation. But still, it is sure to be the subject of a bug report someday. There is an easy although currently non-obvious workaround: End such programs with a call to ForkJoinThread.helpQuiescePool(). This could be made a bit less obscure by adding a (basically identical) method: static void FJP.quiesceCommonPool(); and then document for use in such cases. Otherwise, I don't know of a good alternative. We cannot change to use non-daemon threads, because that would then hold up VM termination until an explicit common pool shutdown, which we don't and can't allow. We could ask that the VM implicitly add a call to quiesceCommonPool to every main(), but that would probably be seen as too disruptive and controversial considering the rare cases it applies. We could also add a shutdown hook calling quiesceCommonPool but because of the lack of ordering guarantees for hooks, this may get called after some other needed resources are blown away. Other ideas? -Doug

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