On 08/10/2025 15:57, Mengyang Li wrote:
```
Console output:
``` bash
WARNING: Using custom default scheduler, this is an experimental feature!
class java.lang.Thread
VirtualThread[#27,VirtualThreadA]/runnable RUNNABLE currentThread
Thread[#3,main,5,main] current is virtual false
java.lang.RuntimeException
at
io.github.dreamlike.CustomerVirtualThreadScheduler.execute(CustomerVirtualThreadScheduler.java:16)
at
java.base/java.lang.VirtualThread.submitRunContinuation(VirtualThread.java:367)
at
java.base/java.lang.VirtualThread.externalSubmitRunContinuationOrThrow(VirtualThread.java:456)
at java.base/java.lang.VirtualThread.start(VirtualThread.java:734)
at java.base/java.lang.VirtualThread.start(VirtualThread.java:745)
at
java.base/java.lang.ThreadBuilders$VirtualThreadBuilder.start(ThreadBuilders.java:257)
at io.github.dreamlike.VTMain.main(VTMain.java:14)
```
After checking the relevant code, it seems that execution goes through
the *first branch* below.
This behavior doesn’t appear to align with the semantics of a custom
scheduler — the nested virtual thread is submitted directly to
ct.getPool() instead of going through
CustomerVirtualThreadScheduler::execute.
Thanks for the mail. You are correct. There is confusion between the
"custom default scheduler" and the "built-in default scheduler" when the
former delegates to the latter. I'll sort it out.
-Alan
