About the VirtualThread Api
Kasper Nielsen
kasperni at gmail.com
Fri Apr 14 09:02:20 UTC 2023
Hi,
Custom schedulers are brought up quite frequently on this list.
If you search the mailing you should be able to find quite a few
discussions about it.
One recent thread is [1].
----
We want to eventually allow custom schedulers but it requires more
exploration. There are issues to work through around the ownership of
monitors and also around blocking operations that temporarily pin a
virtual thread to its carrier.
----
/Kasper
[1] https://mail.openjdk.org/pipermail/loom-dev/2022-November/005094.html
On Fri, 14 Apr 2023 at 09:47, 何品(虎鸣) <hepin.p at alibaba-inc.com> wrote:
>
>
> Hi team, thank for roll this out:
>
> I have a question about the current api of `VirtualThread`. The current `VirtualThread` 's constructor is `
>
> VirtualThread(Executor scheduler, String name, int characteristics, Runnable task)
>
>
> And using a
> private static final ScheduledExecutorService UNPARKER = createDelayedTaskScheduler();
>
> to do all the `unpark` of virtualThread.
>
> What if I Want to implement a `VirturalThread` Scheduler other than the default FPJ based one?And I can even using Netty's `EventLoopGroup` to do this, And the `EventLoop` itself can do scheduling too.
>
> There is no way for user to provide a user specified `Unparker`.
>
> What if we change the constructor to something like:
> VirtualThread(Scheduler scheduler, String name, int characteristics, Runnable task)
>
> where Scheduler can do Scheduling and executing.
>
> Or
>
> VirtualThread(Executor scheduler, ScheduledExecutorService unparker, String name, int characteristics, Runnable task)
>
> Or
>
> VirtualThread(ScheduledExecutorService scheduler, String name, int characteristics, Runnable task)
>
> The Tikio's Scheduler can do the scheduling and do not need another inner unparker.
>
> And I'm would be very happy to hear you, thanks.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
More information about the loom-dev
mailing list