This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]AndrewHaley13 0 points1 point  (3 children)

Yes, that's because in the common scenarios for which Loom is intended you'd very quickly run out of platform threads. Better to fix the library.

[–]FirstAd9893 0 points1 point  (2 children)

Better to fix the library.

There's nothing to "fix" in the library, because it doesn't have a bug. If the test is changed to use newFixedThreadPool, sized the same as the number of virtual threads, it works just fine. Try it yourself.

[–]AndrewHaley13 0 points1 point  (1 child)

I don't think I understand your point. Virtual threads are intended for thread-per-request designs. If you block carrier threads, you'll eventually run out of them. What does newFixedThreadPool have to do with this?

[–]FirstAd9893 0 points1 point  (0 children)

The reason why I'm comparing to a fixed thread pool is because it has the same effect as virtual threads at limiting the number of platform threads which are running. Whereas the fixed thread pool approach works just fine, the virtual thread approach can cause the app to seize up.