Virtual Thread Scheduler - why ForkJoinPool?

[Pedro Lamarão]

Em ter., 4 de out. de 2022 às 12:33, Florian Schmaus <flow at cs.fau.de>
escreveu:


> Basically, VirtualThread.submitRunContination() [1] submits the virtual
> thread's continuation into the fork/join pool. This typically happens
> when a virtual thread is unparked, e.g., when it became runnable again
> after it was blocked on a synchronization primitive.
>


> Work-stealing scheduling is a perfect fit for concurrency platforms like
> Loom, and ForkJoinPool already implemented work-stealing. But I was not
> the one who decided this, so please do not consider this an
> authoritative answer.
>

Is it not the case that a Continuation must always be resumed in the same
thread from where it was started?
(This is my wording for the rule which has been discussed so many times in
this list; I'm not sure what is the official wording for this rule.)
I am assuming that reusing ForkJoinPool here has the intention of allowing
any thread in the pool to pick the Continuation up.
If so, then the Continuation may be resumed by any thread in the pool, not
necessarily the thread from where it was started.
How does this work?

--
 Pedro Lamarão
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20221004/11290cd7/attachment.htm>