ExecutorService that uses current thread as (the only) carrier thread?

[Alan Bateman]

On 24/01/2022 20:47, Simon Herter wrote:
> Hi,
>
> I was wondering if it will be possible to have an ExecutorService that
> spawns a new virtual thread for every task, but yields on 'close' and
> uses the current thread as (the only) carrier thread.
>
>
> Consider the following example:
>
>
>      ReentrantLock lock = new ReentrantLock();
>      lock.lock();
>      try (var e = Executors.newVirtualThreadPerTaskWithCurrentThreadAsCarrierExecutor()) {
>          e.submit(
>              () -> {
>                lock.lock();
>                try {
>                  System.out.println("Hello from " + Thread.currentThread().getName());
>                } finally {
>                  lock.unlock();
>                }
>              });
>      }
>
>
>
> If the current thread is the only carrier thread, this shouldn't deadlock.
>
> Thinking of (badly designed) GUI applications that trigger independent
> blocking I/O operations in a loop in the UI thread, I can imagine that
> this could provide some nice performance improvements without changing
> the design. At least the 'waiting for I/O' can happen in parallel.
>
> Will something like this be part of the JDK? Will we have to implement
> it ourselves? Or is this a stupid idea that cannot work at all?
I think you are asking about "custom schedulers" and whether the UI 
thread could be used as a carrier thread. This capability was exposed 
for some time but it needs more work to explore. So unlikely to be 
exposed in a first release. Experiments with using the AWT event 
dispatching thread (or the equivalent UI thread in other frameworks) as 
a carrier thread were inconclusive. Each virtual thread has its own 
identity and not clear if methods such as isEventDispatchThread would 
have change to test if the underlying carrier thread is the dispatching 
thread or not. A lot more work is required to answer some of the 
questions in this area.

-Alan