On 04/10/2025 14:19, dreamlike_ocean lei wrote:
Hello @loom-dev <loom-dev at openjdk.org <http://openjdk.org>>,
I have been enjoying the new POLLER_PER_CARRIER design in the Loom
repo and I really like the direction it is going.
While building on top of the latest code, I noticed a couple of issues
and would like to ask for clarification.
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.
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.
1.
When calling |Thread.startVirtualThread|, the new virtual thread
does not inherit the scheduler of the calling virtual thread, but
instead uses |DEFAULT_SCHEDULER|. 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.
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.
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.
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.
-Alan
