How non-blocking API works?

9
votes

I've been reading Play Framework documentation and found this quote confusing:

Note that you may be tempted to therefore wrap your blocking code in Futures. This does not make it non-blocking, it just means the blocking will happen in a different thread. You still need to make sure that the thread pool that you are using has enough threads to handle the blocking.

I was under impression that all those non-blocking libs are doing blocking operations in their own thread pools and return Future objects so client code won't be blocking.

But this quote said that it doesn't make it non-blocking. Am I missing something? Is there some advanced magic with non-blocking libs?

1
javamultithreadingasynchronousnonblocking
blocking is not "deadlocking". The resource will be locked from its own perspective, but the UI or whatever main thread is doing will not be waiting for it to become unlocked. But the resource will be locked when it's accessed. For example, a 2nd thread accessing the same resource will take longer than the first one to complete because it will have to wait for the first one to unlock the resource. Or the resource to unlock itself, depending on the model. – Sebas
The whole purpose of Futures or Promises is to smoothen resource access and use. It does not propose an alternate locking mechanism. – Sebas
There is difference between async and non-blocking. I hope this link would help you to understand the difference between these two: programmr.com/blogs/… – Nagaraddi

1 Answers

15
votes

Blocking (as in Blocking IO) in the sense of IO means that the thread which initiated the IO goes to sleep until the IO result is available.

Non-Blocking IO (or Asynchronous IO) tells the relevant driver (the kernel, a DB driver, etc.) to initialize an IO action and then the thread keeps on doing other stuff. depending on the technology you use, you handle asynchronous IO results (which may be even an exception) in callbacks (such in Node.js) , channels (Java) , futures (C++) , promises (newer versions of Node.js), Tasks (.Net), coroutines(C++17) etc.

Asynchronous IO does not use threads to make the IO asynchronous. this is the key point here. throwing a blocking IO action to the thread-pool will not make it asynchronous, its just blocking on another thread, and very non scalable. it will make the threadpool be drained out of threads because they will just block as more and more blocking IO is submitted. as they write in their documentation:

The most common place where a typical Play application will block is when it’s talking to a database. Unfortunately, none of the major databases provide asynchronous database drivers for the JVM

meaning that most of the DB implementation do no provide asynchronous IO for Java - throwing a SQL query to a thread-pool will make the thread-pool thread block. this is what they mean by saying :

Note that you may be tempted to therefore wrap your blocking code in Futures. This does not make it non-blocking, it just means the blocking will happen in a different thread.

as we said before , Asynchronous IO is not Blocking IO on another thread.

An example for a Real asynchronous IO in Java is provided by the standard package java.nio