This idea that a function might not know what to do after it finishes its task can be solved in many ways but they are nearly all variations on the idea of continuation passing - i.e. passing an explicit something to do when the function has finished. 

The simplest and best know of these approaches is to pass a call back function to the non-blocking function that contains the code that is to be executed when the task is complete. 

 onEvent(){ 
 getWorkDone(onCompletion);
 return;
}

The onCompletion function is called when getWorkDone has finished. Notice that onCompletion looks a lot like an event handler and in fact there is very little difference. A call back function is just an event handler that responds to the completion of the non-blocking function. You could adopt a different syntax that allowed the assignment of a callback as if it was an event. For example:

 onEvent(){ 
 getWorkDone.onComplete=onCompletion;
 getWorkDone();
 return;
}

Event handlers tend to be called repeatedly when the event is raised but callbacks tend to be related to one off events like a file finishing downloading. 

Of course things are a little more complicated in that this sort of mechanism seems to modify the natural logic of a function. A function that was:

onEvent(){ 
 getWorkDone();
 onCompletion
 return;
}

is distorted into:

onEvent(){ 
 getWorkDone(onCompletion);
 return;
}

and while this example may not look so bad the reality is usually much worse.

You might think of a function as loading an image, processing the image and then displaying it but you have to convert into a function that starts the download and an event handler that reacts to the completion of the download.

In practice a function could be decomposed into many event handlers or call backs each dealing with the completion of some non-blocking function or other. 

Dealing With Async

Given that asynchronous coding is so prevalent what can we do to make it better.

First we need to try to explain what makes it worse.

Writing a collection of event handlers generally isn't a difficult thing to do and with the condition that they all return fast there isn't really any difficulty. 

Event handlers tend to be self contained and one event handler isn't in any way a continuation of another. 

Where things get difficult is when you make use of a lot of non-blocking functions to make sure that event handlers return fast. The problem here is that calling non-blocking functions means passing call backs or completed event handlers depending on how you want to look at it.

This is fine when you are only calling one non-blocking function to get a task done but this is usually not the case. 

Typically you need to perform a number of tasks and if the functions are blocking you might write:

 funcA();
 funcB();
 funcC();



To convert this to a set of non-blocking functions would result in something like:

funcA(function(){
                 funcB(function(){
                                 funcC();

                                                                         }

                                                   )

                                    }

            )

where it is assumed that each function is passed a callback as its only parameter. That is each function is passed a function which calls the next function in the sequence. Function A calls function B when it is finished and Function B calls function C when it is finished.

This pyramid of doom style callbacks gets much worse in practice. 

For the final example consider a loop:

for(i=0;i<10;i++) funcA(i);

and now convert it into a non-blocking call:

function loop(i){
 if(i>=10) return;
   funcA(i,function(){
        loop(i++);
   }
}(0);

Assuming that funcA takes a callback as its second argument. Yes that's correct an enumeration loop turns into recursion with non-blocking calls. 

However even this isn't the most general case. In this case the function called by the loop don't depend on each others results - if they do then you have 

There are lots of other problems - handling error conditions, dealing with exceptions, conditional execution  and so on. 

All in all asynchronous programming using callbacks in non-blocking functions isn't easy. 

The problem is that writing an algorithm in asynchronous non-blocking style completely destroys the natural logic of the task as expressed in a synchronous blocking form. 

Are there any solutions?

Yes - see Promises, async and await, yield and any number of flow of control libraries that convert the convoluted callback structure into something more familiar. 

We will take a look at these solutions in the second article. 

1. What Is Asynchronous Programming?
2. Managing Asynchronous Code - Callbacks, Promises & Async/Await

Mike James, Founder and Chief Editor of I Programmer is also a prolific author. In addition to his books on specific languages, Programmer's Python: Everything is an Object, Deep C#: Dive Into Modern C#, JavaScript Jems: The Amazing Parts and Programmer’s Guide To Kotlin, 2nd Ed, he has written The Programmer’s Guide To Theory which sets out to present the fundamental ideas of computer science in an informal, and yet informative, way. His latest book is The Trick Of The Mind: Programming and Computational Thought, aimed at programmers and non-programmers alike, which examines the nature of programming and reveals why it is a very special skill.

Related Articles

Task.js Asynchronous Tasks In JavaScript      

jQuery, Promises & Deferred

jQuery Promises, Deferred & WebWorkers

Why await? Why not multithread the UI?       

Async, Await and the UI problem       

To be informed about new articles on I Programmer, sign up for our weekly newsletter, subscribe to the RSS feed and follow us on Twitter, Facebook or Linkedin.

Comments

Make a Comment or View Existing Comments Using Disqus

or email your comment to: comments@i-programmer.info

 <ASIN:1871962528>

<ASIN:1871962501>