Menu
Everyone seems to be talking about Reactive application these days and Reactive manifesto seems to encourage non blocking/asynchronous code. I've seen a ton of videos on youtube where the speakers are encouraging non blocking code but no one says the benefit of writing non blocking code over blocking other than saying
"using futures is good because it is not blocking your code" - some speaker
This is just making "blocking code" sound like a bad word.
My question is simple: If I have a task and I run it with:
The fact is that the actual task I want to run is always going to run on 1 thread in the above two cases. The second option just adds more complexity to the application and the first one is simpler and probably faster since I don't have to delegate.
I understand at some point during the execution of a task there will be a need perform multiple concurrent tasks so Threads/non blocking/async code helps here. But why does Reactive manifesto encourages non blocking applications ground up ? What is the benefit other than a whole bunch of Futures and Promises in your applications which is just making the code more complicated and harder to debug ?
641
In plain terms reactive programming is about non-blocking applications that are asynchronous and event-driven and require a small number of threads to scale. A key aspect of that definition is the concept of backpressure which is a mechanism to ensure producers don't overwhelm consumers.
Non-Blocking methods are executed asynchronously. Asynchronously means that the program may not necessarily execute line by line. The program calls the function and move to the next operation and does not wait for it to return.
In a blocking thread model, when the program carries out a blocking action such as IO, the OS level thread also blocks. In contrast, a non-blocking system does not block an OS thread when the thread needs to block on a blocking operation (e.g. I/O) rather it frees up the OS thread.
Reactive programming describes a design paradigm that relies on asynchronous programming logic to handle real-time updates to otherwise static content. It provides an efficient means -- the use of automated data streams -- to handle data updates to content whenever a user makes an inquiry.
Non blocking code - Where one thread delegates the task to another thread
That's actually not the case. Non-blocking IO comes in all kinds of forms but usually there is no thread blocked while the IO is running. A callback is called when the IO is done.
That's why non-blocking/async IO is so hard to use. It turns your code into callbacks.
Two benefits to non-blocking/async IO: Less threads required and less context switches. In some cases it can make programming with interactive GUIs easier.
Non-blocking/async IO certainly should not be a default choice because it causes loss of productivity.
I have written two standard pieces on this in the .NET context which I will link to: https://stackoverflow.com/a/25087273/122718 Why does the EF 6 tutorial use asychronous calls? https://stackoverflow.com/a/12796711/122718 Should we switch to use async I/O by default?
The concepts should carry over to most platforms.
87
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
