FJP.CommonPool and VM shutdown

[Brian Goetz]

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
>
>