Non-blocking IO / Reactive programming - explanation

by GarciaPL on Monday 2 April 2018

Last time I was looking for an explanation what this "Non-Blocking IO" means. It was hard to understand what it's not blocking and what exactly it does or does not. Moreover, I was trying to find information how this correlates with reactive programming in overall... and I found it! Please check article listed in References. Thanks Adam!

In an old approach called threaded blocking IO, we bound every new connection to a new socket and create a new thread to process the data. This means that there is a single open connection which is managed by the single thread. When a client requests a connection from the server socket it sends back a new socket to communicate with. Now multiple connections can be handled until the limit of the maximum number of threads is reached. Each thread requires memory allocation, so while the concurrent connection goes up, the performance of the server goes down.

Instead of binding the thread to a connection, a notification is sent when the data is ready to read from a buffer. NIO uses buffers instead of streams to read/write data because data is processed when it's already there, not when it's actually being received. With this mechanism, multiple connections can be handled by one thread. That's how finally no threads are blocked while waiting on the IO.
The thread is only responsible for reading the buffers when it's notified about the arrival of any new data. This mechanism is called the 'event loop'. Following that logic, lots of concurrent connections can be handled with just a couple of threads. That's why NIO-based servers are so awesome and serve as our first building blocks.

Reactive programming is about using asynchronous, non-blocking building blocks with a functional style of coding.


References :
[1] Kotlindevelopment.com - Developers guide to Webflux