Consider Wrapping CompletionStages in a ManagedBlocker

[billoneil]

Copying from #283 (comment)

This can potentially be handled in Async.

    static <T> Supplier<T> blocking(Supplier<T> supplier, boolean threadLocal) {

        // [#5377] In ThreadLocal contexts (e.g. when using ThreadLocalTransactionprovider),
        //         no ManagedBlocker is needed as we're guaranteed by API contract to always
        //         remain on the same thread.

        return threadLocal ? supplier : new Supplier<T>() {
            volatile T asyncResult;

            @Override
            public T get() {
                try {
                    ForkJoinPool.managedBlock(new ManagedBlocker() {
                        @Override
                        public boolean block() {
                            asyncResult = supplier.get();
                            return true;
                        }

                        @Override
                        public boolean isReleasable() {
                            return asyncResult != null;
                        }
                    });
                }
                catch (InterruptedException e) {
                    throw new RuntimeException(e);
                }

                return asyncResult;
            }
        };
    }

[lukaseder]

Indeed, we could simply add the method to Async and adapt the arguments for use with the remaining API. For simplicity, I supported the version accepting a Supplier<T> only, but I think we should also have a Runnable version in the public API (which delegates to Supplier<T>.

Also, the threadLocal argument is part of jOOQ's internals, we don't need that in jOOλ.

[lukaseder]

... for the record, unlike in jOOQ where all asynchronous Runnable and Supplier lambdas are blocking (as they contain SQL code), I think in this case we shouldn't automatically use the proposed blocking() wrapper. Instead, we should educate users about this feature through Javadoc and offer it as a standalone, opt-in wrapper.

[billoneil]

Do you think it would be worthwhile to have an implementation of a ManagedBlocker that can optionally be passed in? Or would the use cases vary too much? I could envision the following.

Async.supplyAsync(() -> {...}, executor, ManagedBlockers.blocking());

[lukaseder]

Hmm, what would that blocking() thing return?

[lukaseder]

... having said so, I'm not sure if I find that "blocking" concept strong enough to justify the additional argument to the method