Right now we don't force VTs created via Thread.OfVirtual to run on the custom scheduler, but are forwarded to the built in one.
Since we implemented a non trivial and effective work stealing mechanism, we could just act similarly to FJ:
- if the current VT start a new one, it is considered an internal submission and is posted to the same worker if the internal q is empty, to an external one, If not
- if a non virtual thread start a new VT, it is submitted to a worker via some xorshift mechanism
We currently use the attachment for the current running VT via a scoped value, primary with the purpose of reducing spurious wakeups and to detect rogue JDK per carrier pollers.
It would be good if the fibers branch provide a Thread.OfVirtual.currentVIrtualThreadTask method which would save using the scoped value as it requires all VTs handled to be created through specialized factories, instead common ones.
I will play around adding an experimental feature which enable every VT to run on the custom scheduler
Right now we don't force VTs created via Thread.OfVirtual to run on the custom scheduler, but are forwarded to the built in one.
Since we implemented a non trivial and effective work stealing mechanism, we could just act similarly to FJ:
We currently use the attachment for the current running VT via a scoped value, primary with the purpose of reducing spurious wakeups and to detect rogue JDK per carrier pollers.
It would be good if the fibers branch provide a Thread.OfVirtual.currentVIrtualThreadTask method which would save using the scoped value as it requires all VTs handled to be created through specialized factories, instead common ones.
I will play around adding an experimental feature which enable every VT to run on the custom scheduler