My Event Loop
It might sound funny to say My Event Loop, but after researching the topic in order to get a grasp on the underpinnings of Node.js, I honestly didn’t find complete agreement on what exactly the event loop is. That said, this is my understanding of this important concept and its place in developing with JavaScript.
The image above has been gratuitously stolen from the work of Philip Roberts, a developer I’ve come to know from his talks on the event loop. Actually, he ends up talking about the entire JavaScript runtime, but that’ll be explained later. Below is a version of his talk from JSConf EU 2014.
The Heap
The heap might be interesting to some, but in this context it’s not especially relevant. (Side note: I once had the opportunity to sit down with Bradley Farias, who knows it inside and out, as he tried to explain the heap to me for a project he was working on to try and visualize it. My brain hurted.)
The Stack
The Stack (or call stack) is where all the action happens–except for the other places where the action happens. Anything that can’t be immediately executed gets taken off the Stack and taken care of by another process. This could be Web APIs like those in the picture, or Node APIs like fs or stream. Once this is finished, it gets put on the Queue (or callback queue).
The Event Loop
This is where things get interesting. The Queue only starts pushing items onto the Stack once the latter is empty. The event loop is the mechanism for moving these items from Queue to Stack. If a process takes a long time–like, for instance, an AJAX call–the Stack might clear and the event loop could make a full run, emptying the Queue.
The Queue only starts pushing items onto the Stack once the latter is empty. The event loop is the mechanism for moving these items from Queue to Stack.
From there, the Stack gets back to business and works through any executions it has received. Then the process starts all over again, with the event loop cycling and looking for items to pull from the Queue and push to the Stack. This could theoretically happen into infinity, but probably won’t.
What’s it all mean?
What’s the point of all this academic examination? Well, if one understands the way items will be processed throughout the JavaScript execution cycle, then the most dreaded of consequences can be avoided: blocking. We must take advantage of the asynchronous nature of JavaScript and make sure anything that could eat up valuable milliseconds on the Stack be shuffled off to a worker or a callback.
Performance is improved, processes become more reliable, and Node instances can be scaled to harness the power of this way of doing business. There’s more to say about threads (no, JS isn’t truly single-threaded), but that gets into even deeper weeds, and my legs are already cut up from mowing this grass.
Caveat
Of course, in practice, all of this is much more complicated. Engines like V8 optimize under the hood in ways that might change this process, though the developer and thus user should never be aware of it. A browser itself might have several of these runtimes working simultaneously. (Think web workers.) Still, this mental model works and will help prevent headaches like the dreaded race condition.
