-
I was reading https://github.com/jruby/jruby/releases/tag/9.3.8.0 and noticed:
My understanding is that this means under the hood, fibers will use virtual threads. Based on my understanding of Java so far, playing around with the preview releases, I know that to use virtual threads in Java instead of platform threads, you must explicitly make your new thread a virtual thread as you create it (ex. with But what does this mean for web servers libraries like Puma and unicorn? I remember when using Rails a while ago that Puma, for example, was popular at the time because it used multiple threads to handle more requests concurrently. Will the devs of libraries like it need to switch their code to use fibers to take advantage of virtual threads when they're run using JRuby? Have they already been aware of this for a while now, so that their code uses fibers (which I would assume would be powered by JVM platform threads in JRuby right now) so that those libraries are ready to go right now? |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 2 replies
-
For frameworks that use Fibers (and Enumerators with As for what tools like web servers should do going foward... that depends how they want to achieve concurrency and parallelism. Native threads ( Fiber-heavy servers like Async tend to use only one core (or very few cores) but use that core to drive many fibers, achieving very high concurrency but not very high parallelism. Thread-based servers like Puma use a native thread per request handler to always achieve parallelism but this potentially limits how many concurrent connections can be processed. A gross simplification might be:
I believe both approaches will be valid going forward, as well as hybrid approaches that use both platform and virtual threading. |
Beta Was this translation helpful? Give feedback.
For frameworks that use Fibers (and Enumerators with
next
, which requires a Fiber) users will not have to do anything but enable virtual threads in the JVM to get those advantages. That means frameworks likeasync
, and the defunctcelluloid
should "just work" and be able to scale out far more fibers than before.As for what tools like web servers should do going foward... that depends how they want to achieve concurrency and parallelism.
Native threads (
Thread.new
threads in Ruby) will always get a "platform" thread and run in parallel so long as there's enough cores. Virtual threads (Fiber.new
in Ruby) may run in parallel with native threads (Ruby ties each Fiber to one parent platform t…