Wrapping virtual threads in predefined ExecutorService.

[Holo The Sage Wolf]

It doesn't seem to me that you want to pool virtual threads.

The thread-per-core architecture seems to benefit from using VM threads
directly, and wrapping it with a virtual thread will give you the cost of
the abstraction without the benefits.

If you want the benefits of the programming model of virtual threads (e.g.
not needing to use reactive-like programming) you need to guarantee that
your virtual threads run on a given pool of VM threads, something like e.g.

private static ThreadLocal<ThreadFactory> virtualFactory = new
ThreadLocal<>();

public static void fork(Runnable r) {
    // Run using virtualFactory.get()...
}

public static void main(string[] args) {
    for (/* core in cores */) {
      ThreadPerCoreExecuter(core, () -> {
         virtualFactory.set(Thread
               .ofVirtual()
               .factory(currentThread()));
          // The thread logic, while using `fork`
       });
    }
}

as far as I can remember, this is currently not possible

On Sat, Jun 17, 2023, 07:58 Andrii Lomakin <lomakin.andrey at gmail.com> wrote:

> Hi Attila.
> Cool! I want to implement an architecture that, for example, ScillaDB
> uses. DB instances are sharded not by per server node but by CPU core node.
> That allows us to avoid the usage of memory fences during the usage of
> locks (additionally implemented, of course) and use a wider set of data
> structures (because of the usage of cooperative concurrency).
> There is a very cool presentation about such architecture in Hydar (if you
> are curious to check it) - https://www.youtube.com/watch?v=JPTt1ny67x4
>
>
>
> On Fri, Jun 16, 2023 at 11:34 PM Attila Kelemen <
> attila.kelemen85 at gmail.com> wrote:
>
>> Sorry, wrong copy paste, instead of
>> `Executors.newVirtualThreadPerTaskExecutor()` I meant
>> `Thread.ofVirtual().factory()` of course.
>>
>> Attila Kelemen <attila.kelemen85 at gmail.com> ezt írta (időpont: 2023.
>> jún. 16., P, 23:30):
>>
>>> `ThreadPoolExecutor` already allows a custom `ThreadFactory` to which
>>> you can pass `Executors.newVirtualThreadPerTaskExecutor()`. However, why
>>> would you create a new server using loom on thread/core when you want to
>>> rely on virtual threads? That just means that you are pooling virtual
>>> threads which seems to be pointless (basically you are creating a queue in
>>> order to put them in another). If you want to limit the number of
>>> concurrent access, then you can do that with a semaphore.
>>>
>>> Attila
>>>
>>> Andrii Lomakin <lomakin.andrey at gmail.com> ezt írta (időpont: 2023. jún.
>>> 16., P, 7:59):
>>>
>>>> Good day devs!
>>>>  I am considering the creation of a database server that is working on
>>>> thread-per-core architecture. So I have a question: do you have plans to
>>>> implement the possibility of using virtual threads executor on the base of
>>>> a passed executor?
>>>>
>>>> P.S. I am aware of problems with synchronization inside JDK classes,
>>>> libraries, and pinned threads.
>>>>
>>>> --
>>>> Best regards,
>>>> Andrii Lomakin.
>>>>
>>>>
>
> --
> Best regards,
> Andrii Lomakin.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20230617/67f13055/attachment-0001.htm>