Wrapping virtual threads in predefined ExecutorService.

[Andrii Lomakin]

Yes, that is what I intended to say.
I apologize for any confusion. Is there a plan to incorporate this feature
in the future?

On Sat, Jun 17, 2023 at 11:04 AM Holo The Sage Wolf <holo3146 at gmail.com>
wrote:

> 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.
>>
>>

-- 
Best regards,
Andrii Lomakin.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20230617/f0c9b3aa/attachment.htm>