<div dir="ltr">Yep I am aware of that. Each "workflows" thread's execute in a serialized fashion. Workflows themselves are like processes and are not allowed to communicate with each other except over specific determentics channels. I do the same in my custom scheduler.</div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Tue, Jun 24, 2025 at 10:10 AM Robert Engels <<a href="mailto:robaho@me.com">robaho@me.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div dir="ltr"></div><div dir="ltr">Concurrent programming in inherently non deterministic. The only way to provide determinism is via locking and other concurrent synchronization methods. If you are trying to execute workflows concurrently that have shared state/resources - they themselves must use locking semantics to communicate. </div><div dir="ltr"><br></div><div dir="ltr">Without these, this typically degenerates to single threaded serialized execution due to required correctness guarantees. </div><div dir="ltr"><br></div><div dir="ltr">These are the laws of concurrent composition - not mine :)</div><div dir="ltr"><br><blockquote type="cite">On Jun 24, 2025, at 11:57 AM, Quinn Klassen <<a href="mailto:quinn.klassen@temporal.io" target="_blank">quinn.klassen@temporal.io</a>> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><div dir="ltr">Sure, to be clear I am not doing deterministic testing. I maintain a durable execution framework in Java (<a href="https://github.com/temporalio/sdk-java" target="_blank">https://github.com/temporalio/sdk-java</a>). 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.<br><br>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.<br><br>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.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jun 24, 2025 at 8:58 AM Alan Bateman <<a href="mailto:alan.bateman@oracle.com" target="_blank">alan.bateman@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u>

  
  <div>
    <br>
    <br>
    <div>On 22/06/2025 23:24, Quinn Klassen
      wrote:<br>
    </div>
    <blockquote type="cite">
      
      <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>
  </div>

</blockquote></div>
</div></blockquote></div></blockquote></div>