5

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:

  1. Blocking code - Where runs the task on one thread
  2. Non blocking code - Where one thread delegates the task to another thread

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 ?

user794783
  • 3,619
  • 7
  • 36
  • 58

1 Answers1

5

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.

Community
  • 1
  • 1
usr
  • 168,620
  • 35
  • 240
  • 369
  • Very helpful answer. I didn't know async IO turns code in callbacks. But by IO you mean disk read and write, correct ? So my async code will only get turned in callbacks for disk or RAM related tasks ? But if I'm just run async inside my code which is not RAM or Disk intensive, that will not be executed as callback ? – user794783 Oct 21 '15 at 09:31
  • 1
    Anything that's running on the CPU/RAM has no need for async calls (except if it is to unblock the GUI thread). You can decide on a case by case basis what to call asynchronously. The best places are those with high wait times and high frequency. Usually, it only makes sense to make network things async. – usr Oct 21 '15 at 09:34
  • So if only makes sense to make network things async & some obvious situations where concurrent/parallel execution of code is necessary, other than that async is just adding complexity to the application and people suggesting to implement an async application all the way through is not going to increase application performance or help in any other way ? – user794783 Oct 21 '15 at 09:40
  • 1
    No, it is not going to result in any throughput improvement at all most of the time. Most people doing it are misguided. In particular all socket tutorials for some reason use async IO even when there are only ever going to be 10 clients or so. Total waste of dev time. Stack Overflow is very prone to group think in this particular case. – usr Oct 21 '15 at 09:48