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.