Few common misconceptions about node's event loop

Published Feb 26, 2018Last updated Mar 21, 2018

As a computer science student, I already had a little idea of different types of languages from my college days. You know, C, C++ etc. Knew about C# as well and used to think that this is an amazing language and I definitely will try my best to work with that in the future.
However, when I got a job, I was asked to code pretty much in a JavaScript environment.

I didn't like it very much. Single threaded scripting language... the phrase itself sounds weird 😄. Anyway, as a fresher engineer in an Indian company, you really don't have much choice with you. Thus, I started coding with JavaScript.

Soon after I started coding in JavaScript, I came to know about event loop. For first few months I used to feel that this is some kind of a magic 😛.
Yeah, seriously! I mean if you are an average college passout and have only worked with C/C# type of languages who all are synchronous; and someday someone says there is a language which has a single thread and never blocks; you will obviously consider it a magic 😄

Anyway, I eventually read a lot about the event loop from the internet and kind of understood how it works. But unfortunately due to many wrong explanations or very high level view of the same, it created some misconceptions in our (or atleast my) mind.


Today in this article I'm going to highlight some of them. In case you don't know how node.js event loop internally works, you can read that once.

I have not checked how event loops in browsers work, but believe they will be somewhat similar. All my comments below are for the event loop os node js.

Where is the loop?

Myth: Event-loop is a part of v8 or other javascript engines. Or sometimes people think Event loop is not really a part of JavaScript, but browsers and node implemented it for themselves.

Fact: Event loop is not a part of v8 or any other JavaScript engine. But it is indeed a part of JavaScript. The lifecycle of a JavaScript program lies in the event loop and it is the event loop which commands the v8 or other js engines to execute functions/code.

There is a stack or queue

Myth: To make people understand how event loop works, people often used a stack or a single queue. Seems like every callback, whenever matured is pushed to that.

Fact: First of all there is no stack. And neither there is just a single queue. There are multiple phases in the event loop with multiple queues (other data-structures too) attached in it.

Event loop runs in a separate thread

Myth: Due to the wrong diagram of the event-loop of node.js, some of us think, only the execution of JavaScript is synchronous and thus in a single thread and the event loop runs independently and handles parallel requests in another (or many) separate thread.

Fact: There is just a single thread. Both event loop and javascript execution is running in a single thread. The loop will not propagate when JS execution is going on and the vice versa.

Some async OS api involved in setTimeout

Myth: The times like setTimeout an setInterval are something handled by some third party, may be OS, who automatically notifies if the time is elapsed and then it got inserted into the queue.

Fact: The reality is, timers are stored in a min-heap memory in sorted order and event loop while going through the timer phase or poll phase, check the timer scrips by simple mathematical operation like, now - registeredTime > delta and executes the callbacks.

setImmediate places the callback at 0th position

Myth: As majority consider that there is a single job queue in JavaScript eco system; when setImmediate api was introduced, people couldn't figure out where to put that for their understanding and thus some of the blogs came up saying that setImmediate puts the callback infront of the queue.

Fact: The setImmediate has a different phase and thus a different queue dedicated to it. Any job queue in JavaScript ecosystem is always FIFO. Same for check phase or setImmediate phase. Only difference is, after waiting in the poll phase, the event loop next goes inside the check phase to execute the callbacks invoked by setImmediate.


Myth: Everything that is asynchronous is handled by event loop which uses a threadpool internally.

Fact: Threadpool doesn't handle every single asynchronous request. If libUV finds that the particular task can be done using OS's asynchronous apis, it uses them. If there are cases where no async api from OS is not available, like file read, dns lookup etc; then libUV uses the threadpool whose default size is just 4 and can be extended using the UV_THREADPOOL_SIZE environment variable till 128.

Discover and read more posts from Paul Shan
get started