Custom Schedulers: Customize current time and timed waits

[Quinn Klassen]

Sure, to be clear I am not doing deterministic testing. I maintain a
durable execution framework in Java (https://github.com/temporalio/sdk-java).
To give a very brief overview, users can write "programs" (we call them
workflows) using our APIs and we'll make them fault tolerant. We do this by
recording what the program is doing into an event log so the workflow can
be resumed if the original host crashes. To be able to replay the event log
and resume the program we need the workflow to be deterministic.
Obviously that requirement is problematic when multiple threads are
involved so we have to disallow users from using the standard java library
to start threads and use our wrappers instead. that we can make
determentisic.

In most of the other languages we support like Python, Ruby, Dotnet, Rust,
Javascript we can control the thread/task scheduling so users can use more
of the languages native constructs. This makes our Java SDK harder to use
than some of our other SDKs.

Yeah I understand that the current experimental interface is deliberately
minimal right now. I just wanted to give my feedback/suggestion as a user
who has, in my humble opinion, an interesting use case that a lot of other
languages with a custom scheduler do support.

On Tue, Jun 24, 2025 at 8:58 AM Alan Bateman <alan.bateman at oracle.com>
wrote:

>
>
> On 22/06/2025 23:24, Quinn Klassen wrote:
>
> :
>
> For timed operations ideally I would like the virtual thread to request
> the scheduler it wants to do a timed operation and the scheduler decides
> how to accomplish this. That may be too high level an interface to add
> since it looks like more libraries use `
> java.util.concurrent.locks.LockSupport`. This is my first time looking at
> the implementation of some of these low level calls, but maybe it would be
> more realistic to allow a pluggable time source and interception of these
> parking utilities.
>
> Can you say a bit more about what you are doing? Mike Hearn mentioned
> deterministic testing but I can't tell from your mails if this is what you
> are doing.
>
> In any case, the experimental interface for the scheduler is deliberately
> minimal. If a virtual thread waits in timed-Object.wait for example, then
> controls returns to scheduler. When the virtual thread can continue then
> its task will be queued to the scheduler to execute. This may be triggered
> by an Object.notify, timeout + monitor reacquired, interrupted + object
> reacquired. So triggered by the VM or other parts of the runtime. Also
> timeout is just one of the cases that causes a thread to continue. It's the
> same with LockSupport.parkNanos. I don't know if you are expecting the
> custom scheduler (essentially arbitrary code) to run at these critical
> times but right now, the scheduler is just used to execute tasks.
>
> -Alan
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20250624/3b64a12e/attachment-0001.htm>