Scheduler API Feedback

[Alan Bateman]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20251008/16d2e100/attachment.htm>