Menu
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?
347
Non-blocking IO under the hood Most non-blocking frameworks use an infinite loop that constantly checks (polls) if data is returned from IO. This is often called the event loop. An event loop is literally a while(true) loop that in each iteration will check if data is ready to read from a network socket.
A Netty Event Loop is a loop that keeps looking for new events like incoming HTTP requests. When an event occurs, it is passed on to the appropriate event handler. The Event Loop doesn't wait for request processing finish. It means it's a non-blocking HTTP server.
Non blocking I/O operation improves the software's speed and processing, but there are some disadvantages. It's only effective for I/O heavy workloads. In workloads that have more I/O work than CPU work, the efficiency gain from non-blocking I/O is much higher, as you might expect.
In computer science, an algorithm is called non-blocking if failure or suspension of any thread cannot cause failure or suspension of another thread; for some operations, these algorithms provide a useful alternative to traditional blocking implementations.
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
158
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
