Even experts can unintentionally build race conditions into their code. Even they can easily overlook the side effects when multithreading suddenly interrupts the flow of code. Emergency teams later have to discover the causes, which involves a huge amount of effort. After all, the error the customer reports occurs only sporadically, because it only occurs given the temporal coincidence of certain events that cannot be easily reproduced by the development department.

One Thread Is Enough

If only one thread is running – as in a JavaScript application – then there can be no such race conditions, because the CPU runs the code as written, and nothing unexpected interrupts the flow. In other words, this approach has its benefits.

For a program with only one thread to run as fast as one with multiple threads, however, it must not be allowed to sit and twiddle its thumbs while, for example, a much slower network operation is in progress. To allow this to happen, the programmer relinquishes control over selected parts of the program to an event loop, which executes the events asynchronously. Once a programmer's brain has mastered the jump to asynchronous program flows, even complicated processes are wonderfully easy to write. Before that happens, however, some hurdles must be taken.

Hipster, Help!

Some people take a long time to understand asynchronous program flow. The resurrection of JavaScript as a hipster language, especially on the server side with the fully asynchronous Node.js framework, brought to light some of the familiar and typical stumbling blocks. Some elegant solutions (e.g., PubSub, Promises, or entire frameworks like Async.js) have lately emerged to help tame the asynchronous flow of complex applications [1].

Asynchronous flow is something that newcomers also perceive as a limitation in Perl, because all of a sudden they cannot, for example, easily retrieve the content of a website with the LWP::User-Agent CPAN module and a call such as:

$ua->get("http://foo.com");

Because get() is waiting for the response from the web server, and the data is slowly trickling in, all of the application cogwheels are standing still, which is truly undesirable if you want snappy performance. Instead, everything now relies on callbacks, as in the following example with the AnyEvent framework:

http_get("http://foo.com", sub { print $_[1] } );

The program simply issues the order to get the website and returns to the main program immediately after calling the http_get() function. The event loop has accepted the job and only takes care of retrieving and collecting the data when the program again takes a break. Once everything is in place, the global event loop calls the previously attached callback with the acquired data, which it outputs using the print statement.

However, this structure really messes up the program flow of an application:

http_get($url1,
   sub {
      http_get($url2, sub {
         # ...
      });
 });

If multiple web requests occur in quick succession, whose queries involve previously retrieved results, nesting can quickly take on dimensions that are difficult to understand.

Pyramid of Doom

If not handled correctly, the callback method quickly leads to what is known as the "Pyramid of Doom." This refers to nested functions, where each callback defines another callback. At some point, even the widest screen is no longer wide enough to write out the program flow, not to mention the fact that such code is extremely difficult to read and comprehend. Who would argue with this statement given Listing 1?

This simulates the problem that arises when the result of a web request flows into the next request, that is, where several web requests depend on one another. They can be processed asynchronously but need to keep to a predetermined order. To illustrate this, the script in Listing 1 [2] uses CountServer, a test server, which responds to requests on the URL http://localhost:9090 by returning another URL – in each case with a numerical path component incremented by 1:

$ curl http://localhost:9090/test-1.txt
http://localhost:9090/test-2.txt
$ curl http://localhost:9090/test-2.txt
http://localhost:9090/test-3.txt
$ curl http://localhost:9090/test-5.txt
http://localhost:9090/test-6.txt

The test client in Listing 1 starts the first asynchronous web request with the string /test-1.txt; in response, it receives the string /test-2.txt, which then sends the second request and receives test-3.txt in return. The actual output from http-get-nested in Listing 1 is:

$ ./http-get-nested
Got: http://localhost:9090/test-2.txt
Got: http://localhost:9090/test-3.txt
Got: http://localhost:9090/test-4.txt

This confirms that although the code is quite difficult to understand, it is still quite functional. The CountServer.pm code shown in Listing 2 is a very easy and simple Perl class whose start() method launches a web server from the CPAN AnyEvent::HTTPD module. The reg_cb() in line 22 lets the web server register a handler for incoming requests and thus return the path information to the requesting web client incremented by precisely 1 in each case.

If you're used to traditional sequenced programming and think you need to launch an external web server to test a web client, you may be scratching your head by now and suspecting some kind of sorcery. In the asynchronous world, however, it is common practice to run both server and client for testing purposes at the same time, in same program. This converts a unit test into an integration test!