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

Brian Goetz brian.goetz at oracle.com
Tue Jan 1 10:20:55 PST 2013

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.

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