insights 153 - Virtual Thread pooling

[guykatz]

hi all,
in the latest insight something similar to the following was stated:
'its already hard dealing with 5 thread deadlock so image a million thread deadlock.'
and this is exactly why i think that in some cases you might want to consider pooling virtual thtreads.
most of the apps out there are buggy already, and virtial threads are not a silver bullet.
for code that is buggy, porting to VT, its very possible to get to that miilion thread contention pretty easaly.
some docs suggest that you can use some sort of rate limit semaphore which indirectly can help. But TBH, with the current executor framework you can easialy pool virtual threads using a VT factory and when code is buggy you are most likely to benefit from this (assuming you will not create other bugs in the process)

I understand what I say is somewhat of an abomination but like i said, virtual threads are not a silver bullet and it likely to amplify your already buggy code in many cases.
(i am not talking about the quarkus implementation with v thread of course, I am talking generaly about using v threads in your app explicitly)

[cescoffier]

I agree. For messaging, we have added a semaphore to limit the concurrency. We are also working on channels to control the number and communication between virtual threads. I don't know when we will have something "showable" about this project - hopefully soon.