java.lang.ThreadBuilders and java.lang.ThreadBuilders.newVirtualThread() are not public

[Rick Hendricksen]

Hi Alan,

Thanks for taking the time to help us with this issue.

We see three problems with using the default scheduler with maxPoolSize:

  *   Other virtual threads which are not directly related to the simulation would slow down the simulation
  *   Running multiple simulations in parallel would not be possible
  *   We need full control over which thread runs, and how to treat yield. If the thread is yielding because of a simulation-related blocking operation, we want to run the next thread. If it’s yielding due to IO, we don’t want to switch to another thread. If IO wait would result in a yield, that would be unpredictable, and would affect the result of our simulation.

It would be very helpful for us if custom schedulers would be exposed. Could you tell us more about the explorations you mentioned? And is it an option to take our use case into account there?


Best regards,

Rick Hendricksen

From: Alan Bateman <alan.bateman at oracle.com>
Sent: Tuesday, 20 August 2024 17:45
To: Rick Hendricksen <Rick.Hendricksen at vanderlande.com>; loom-dev at openjdk.org
Cc: Dennis van den Berg <Dennis.van.den.Berg at vanderlande.com>
Subject: Re: java.lang.ThreadBuilders and java.lang.ThreadBuilders.newVirtualThread() are not public

Be aware: This email was created outside of Vanderlande. Be cautious of its contents and do not click any links or attachments unless you recognise the sender and know the content is safe.

On 20/08/2024 16:32, Rick Hendricksen wrote:


Hi,

We have implemented a Discrete Event Simulator, and we want to use virtual threads to write our business logic (that uses the DES) in a more readable way. This business logic has a lot of blocking operations, so it seems to be a good fit for virtual threads. However, we must ensure that all those virtual threads run on the same carrier thread, because the simulation has to be deterministic. We also often run multiple separate simulations in parallel, so it’s important that virtual threads end up on the right scheduler. This means we need to use our own scheduler.
Can the simulation be run with a single carrier thread (-Djdk.virtualThreadScheduler.maxPoolSize=1) ?

There are a number of explorations into using custom schedulers but impossible to say at this point if anything will be exposed.

-Alan
________________________________

** Disclaimer **

This e-mail, including any attachments, may include proprietary and confidential information of Vanderlande and may only be read by the person or those persons to whom it is addressed.
This document is forwarded to you in such a form (e-mail) that Vanderlande cannot guarantee the completeness and/or correctness of its contents and information.
If you have received this e-mail message in error, please notify us immediately.
Please also delete this document from your computer.
This document may not be reproduced, copied, distributed, published, modified, or furnished to third parties, without the prior written consent of Vanderlande.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20240821/8f31effa/attachment-0001.htm>