<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<div class="moz-cite-prefix">On 04/10/2025 14:19, dreamlike_ocean
lei wrote:<br>
</div>
<blockquote type="cite" cite="mid:CAJ_HiMsGGoKOUrWQVDoYD5Fm1qszDB_MrOK0iuzryC8=_qanjw@mail.gmail.com">
<div dir="ltr">
<p>Hello @loom-dev <loom-dev at <a href="http://openjdk.org" moz-do-not-send="true">openjdk.org</a>>,</p>
<p>I have been enjoying the new POLLER_PER_CARRIER design in the
Loom repo and I really like the direction it is going.<br>
While building on top of the latest code, I noticed a couple
of issues and would like to ask for clarification.</p>
</div>
</blockquote>
Thanks for your mail. It's useful to hear from folks that are trying
out the experimental support for custom schedulers in the loom repo
as this will help to inform whether any of the directions prototyped
should be taken further.<br>
<br>
BTW: I assume "dreamlike_ocean lei" isn't your real name. It would
be helpful to use a real name or affiliation so we have some idea
who you are.<br>
<br>
<blockquote type="cite" cite="mid:CAJ_HiMsGGoKOUrWQVDoYD5Fm1qszDB_MrOK0iuzryC8=_qanjw@mail.gmail.com">
<div dir="ltr">
<ol>
<li>
<p>When calling <code>Thread.startVirtualThread</code>, the
new virtual thread does not inherit the scheduler of the
calling virtual thread, but instead uses <code>DEFAULT_SCHEDULER</code>.
What is the reasoning behind this design? Could there be a
mechanism to allow implicit inheritance? This would be
very helpful for custom schedulers based on the per-core
model.</p>
</li>
</ol>
</div>
</blockquote>
In a system with several virtual thread schedulers in use, which I
think is what you mean, then it would be unpredictable and
problematic to inherit the scheduler in many cases. If some library
were, on first usage, start a virtual thread as a "background
thread" that runs indefinitely then inheritance would mean it
depends on the first usage. Examples where inheritance at thread
create time is problematic are the thread context class loader, and
until recently, the inherited access control context.<br>
<br>
When you say "custom schedulers based on the per-core model" do you
mean you are experimenting with a scheduler per core in order to get
"carrier affinity" (virtual thread X will always be scheduled on
carrier Y). You might also be using processor affinity to bind
carrier Y to specific sets of CPUs. <br>
<br>
You might find it simpler to just use one scheduler and keep a
mapping of virtual thread to carrier. That would remove
complications with lifecycle that would arise if carriers were to
terminate (e.g. idle/keep-alive). It might avoid needing to expose
APIs to get a virtual thread's scheduler, which I think what your
second point is about.<br>
<br>
-Alan<br>
</body>
</html>