On 13/10/2025 18:52, Mengyang Li wrote:
:
I came up with a new idea — what if we provide an additional Delay
interface?
If the current scheduler implements this interface, we can use the
scheduler’s own delay method.
Otherwise, we fall back to `DelayedTaskSchedulers.schedule`.
Currently, Loom only optimizes ForkJoinPool for this case.
``` java
VirtualThreadScheduler scheduler(boolean revealBuiltin) {
if (scheduler instanceof BuiltinDefaultScheduler builtin &&
!revealBuiltin) {
return builtin.externalView();
} else {
return scheduler;
}
}
```
But if I use Netty’s EventLoop as the scheduler, being able to
implement delay based on the event loop would be fantastic.
For now, the experimental/prototype for custom schedulers will only call
out to the custom scheduler to execute a task that starts or continue a
virtual thread. The VirtualThreadScheduler interface could be extended
to allow the custom scheduler to take on delayed tasks but these are not
virtual thread tasks, they are tasks to support timed-Object.wait for
timed-park. You are right that a SPTE based implementation is used in
the JDK when there is a custom scheduler configured. Is this causing an
issue? Timeouts are usually cancelled, >99% in many cases, so I'd like
to understand if your workloads are different, maybe you have more
scenarios where a timeout occurs?
-Alan
