Wrapping virtual threads in predefined ExecutorService.

[Andrii Lomakin]

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/dde1f4ae/attachment.htm>