Blocked Threads

Interpreted languages

Managed runtime languages such as C#, Java, and Ruby almost never really crash. Sure, they receive application errors, but it’s relatively rare to see the kind of core dump that a C or C++ program would have. Here’s the catch about interpreted languages: the interpreter can be running, and the application can still be totally deadlocked, doing nothing useful.

Application failures

As often happens, adding complexity to solve one problem creates the risk of entirely new failure modes. Multithreading makes application servers scalable enough to handle the web’s largest sites, but it also introduces the possibility of concurrency errors.

Navel-gazing

The most common failure mode for applications built in these languages is navel-gazing, a happily running interpreter with every single thread sitting around waiting for Godot. Multithreading is complex enough that entire books are written about it. For the Java programmers: the only essential book on Java is Brian Goetz’s excellent Java Concurrency in Practice [Goe06]. Moving away from the “fork, run, and die” execution model brings us vastly higher capacity but only by introducing a new risk to stability. The majority of system failures we have dealt with do not involve outright crashes. The process runs but does nothing because every thread available for processing transactions is blocked waiting on some impossible outcome.