<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<br>
<br>
<div class="moz-cite-prefix">On 22/06/2025 23:24, Quinn Klassen
wrote:<br>
</div>
<blockquote type="cite" cite="mid:CAPg4LcRkKajd+msvZpqpcF-WQJQU3zroufKVFhP_jOZwacgHQQ@mail.gmail.com">
<div dir="ltr">:
<div><br>
</div>
<div>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 `<span style="color:rgb(53,56,51);font-family:"DejaVu Sans",Arial,Helvetica,sans-serif;font-size:14px">java.util.concurrent.locks.LockSupport</span>`<span style="color:rgb(53,56,51);font-family:"DejaVu Sans",Arial,Helvetica,sans-serif;font-size:14px">. </span>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.</div>
</div>
<br>
</blockquote>
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.<br>
<br>
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.<br>
<br>
-Alan<br>
<br>
<br>
</body>
</html>