How Perl programmers efficiently manage asynchronous program flows
Pyramid of Doom
Asynchronous program flow quickly degenerates into unreadable code if it lacks an overarching concept to provide structure. Fortunately, the JavaScript community has invented some functional tricks that also help tame asynchronous Perl code.
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?
Listing 1
http-get-nested
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.
Listing 2
CountServer.pm
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!
Buy this article as PDF
(incl. VAT)
Buy Linux Magazine
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters
Support Our Work
Linux Magazine content is made possible with support from readers like you. Please consider contributing when you’ve found an article to be beneficial.
News
-
AlmaLinux OS Kitten 10 Gives Power Users a Sneak Preview
If you're looking to kick the tires of AlmaLinux's upstream version, the developers have a purrfect solution.
-
Gnome 47.1 Released with a Few Fixes
The latest release of the Gnome desktop is all about fixing a few nagging issues and not about bringing new features into the mix.
-
System76 Unveils an Ampere-Powered Thelio Desktop
If you're looking for a new desktop system for developing autonomous driving and software-defined vehicle solutions. System76 has you covered.
-
VirtualBox 7.1.4 Includes Initial Support for Linux kernel 6.12
The latest version of VirtualBox has arrived and it not only adds initial support for kernel 6.12 but another feature that will make using the virtual machine tool much easier.
-
New Slimbook EVO with Raw AMD Ryzen Power
If you're looking for serious power in a 14" ultrabook that is powered by Linux, Slimbook has just the thing for you.
-
The Gnome Foundation Struggling to Stay Afloat
The foundation behind the Gnome desktop environment is having to go through some serious belt-tightening due to continued financial problems.
-
Thousands of Linux Servers Infected with Stealth Malware Since 2021
Perfctl is capable of remaining undetected, which makes it dangerous and hard to mitigate.
-
Halcyon Creates Anti-Ransomware Protection for Linux
As more Linux systems are targeted by ransomware, Halcyon is stepping up its protection.
-
Valve and Arch Linux Announce Collaboration
Valve and Arch have come together for two projects that will have a serious impact on the Linux distribution.
-
Hacker Successfully Runs Linux on a CPU from the Early ‘70s
From the office of "Look what I can do," Dmitry Grinberg was able to get Linux running on a processor that was created in 1971.