Route all VT creation through scheduler.newThread() for custom schedulers#225
Route all VT creation through scheduler.newThread() for custom schedulers#225franz1981 wants to merge 1 commit into
Conversation
|
👋 Welcome back franz1981! A progress list of the required criteria for merging this PR into |
|
❗ This change is not yet ready to be integrated. |
…lers When a custom scheduler is installed via implClass, all VT creation routes through scheduler.newThread(String, int, Thread, Runnable) — the new raw-params overload. The existing builder overload delegates to it, extracting name and characteristics from the builder. Single routing point in newVirtualThread(): when scheduler is null and CUSTOM_SCHEDULER is true, routes through the default scheduler's raw newThread(). No cycle — the raw default creates VirtualThread directly. For paths without a builder (startVirtualThread, factory), uses no builder allocation — raw params are passed directly. CUSTOM_SCHEDULER is static final, JIT constant-folds for builtin.
franz1981
force-pushed
the
newthread-routing
branch
from
60e1a80 to
9be998f
Compare
| * @see <a href="Thread.html#inheritance">Inheritance when creating threads</a> | ||
| */ | ||
| default VirtualThreadTask newThread(Builder.OfVirtual builder, | ||
| default VirtualThreadTask newThread(String name, int characteristics, |
There was a problem hiding this comment.
characteristics is JDK internal implementation default so cannot be exposed with the API like this.
There was a problem hiding this comment.
I know, I mentioned it in the first desc
I dislike to pass/intercepts raw VT parameters
That's what I meant 🙏
This is just a PoC to show the idea: currently there are different routes (builders/factories and raw VT start), and unify them to all go through the scheduler::newThread which uses a builder is not still right
2 participants
When a custom scheduler is installed via implClass, all VT creation routes through scheduler.newThread(String, int, Thread, Runnable) — the new raw-params overload.
The existing builder overload delegates to it, extracting name and characteristics from the builder.
Single routing point in newVirtualThread(): when scheduler is null and CUSTOM_SCHEDULER is true, routes through the default scheduler's raw newThread(). No cycle — the raw default creates VirtualThread directly.
For paths without a builder (startVirtualThread, factory), uses no builder allocation — raw params are passed directly.
This is a PoC which show 2 things:
newThreadmethod can wrap itsRunnablewith aScopedValuewhich can help with Add VirtualThreadScheduler.currentVirtualThreadTask() default method #224: still duplication (as it is now, which is not great), but enable every VT to run with such context.preferredCarrier != nullinfo, a custom scheduler can "treat" differently (by forcing some specific scheduling policy) suchVirtualThreade.g. JDK pollersOther 2 things:
schedulerfield, this looks more messy than it could, sorry for that: with the unified "custom scheduler" API probably there's no reason to have per-builderschedulerfieldsProgress
Reviewing
Using
gitCheckout this PR locally:
$ git fetch https://git.openjdk.org/loom.git pull/225/head:pull/225$ git checkout pull/225Update a local copy of the PR:
$ git checkout pull/225$ git pull https://git.openjdk.org/loom.git pull/225/headUsing Skara CLI tools
Checkout this PR locally:
$ git pr checkout 225View PR using the GUI difftool:
$ git pr show -t 225Using diff file
Download this PR as a diff file:
https://git.openjdk.org/loom/pull/225.diff