Does a blocking IO in Quasar's fiber block a thread in its threadpool?

Question

As far as I know, in Akka , all actors are scheduled over a pool of threads. Too many actors perform blocking IO simultaneously, each blocking call blocks one thread, results in a thread outage.

Now I'm looking at an interesting fiber implementation on JVM -- Quasar which allows lots of user threads -- fibers -- and uses a thread pool to schedule them. However, I'm wondering whether there's benefits when many fibers call legacy blocking APIs.

I don't think it would help because that a blocking API still would block a system thread and Quasar couldn't magically turn it to only block a fiber. That's only my guess, please correct me if I'm wrong.

Answer 1

Quasar fibers are implemented as continuation tasks created and scheduled (by default, but this is customizable even per-fiber if you so wish) on a ForkJoinPool .

You're right, Quasar won't "magically" transform a JDK/JVM thread into a fiber, so at present a thread-blocking call will block a thread in the thread pool (and Quasar will print warnings when that happens). If it happens for a short time and infrequently this is not a big issue, else it's better to do something about it.

If you're lucky though, which is likely and it's getting more and more likely , someone has already written an integration module for your thread-blocking API and has provided a fiber-blocking implementation of it. If this is the case then you only need minor changes (if any at all) to your code in order to switch from inefficient thread-blocking to efficient fiber-blocking.

Else you can build your own luck and write an integration yourself, which is usually very easy . If you do so, please consider integrating it back into Comsat .