#Nw.js application walkthrough code#

Speaking of which, let's understand that next. Nevertheless, they are still part of the Node runtime and play an important role in the order of execution of callbacks. The two microtask queues, however, are not part of libuv. It is important to note that the timer, I/O, check, and close queues are all part of libuv.

Promise queue which holds callbacks associated with the native Promise in JavaScript.

nextTick queue which holds callbacks associated with the process.nextTick function.

Fourth, there is the close queue which holds callbacks associated with the close event of an async task.įinally, there is the microtask queue which contains two separate queues.

Third, there is the check queue which holds callbacks associated with the setImmediate function, which is specific to Node.

Second, there is the I/O queue which contains callbacks associated with all the async methods such as methods associated with the fs and http modules.

First, there is the timer queue (technically a min-heap), which holds callbacks associated with setTimeout and setInterval.

If two async tasks such as setTimeout and readFile complete at the same time, how does Node decide which callback function to run first on the call stack? Does one get priority over the other?Īll of these questions can be answered by understanding the core part of libuv, which is the event loop.

What about other async methods like setTimeout and setInterval, which also delay the execution of a callback function?.

Does Node wait for the call stack to be empty before running the callback function, or does it interrupt the normal flow of execution to run the callback function?.

When an async task completes in libuv, at what point does Node decide to run the associated callback function on the call stack?.

However, that does inspire a few questions. For async operations like reading a file that has no native OS support, libuv relies on its thread pool to ensure that the main thread is not blocked. For async operations like handling a network request, libuv relies on the operating system primitives. It is pretty clear libuv helps handle asynchronous operations in Node.js. The console output is going to read 'First', 'Third', and then 'Second'.

#Nw.js application walkthrough code#

There's no more code to run, so the global function is also popped off the stack. As there are no more statements to execute in the callback function, it is popped off as well. That is pushed to the call stack, 'Second' is logged to the console, and the log function is popped off. Within the callback function, the log statement is encountered. The associated callback function is now executed on the call stack. At 3ms, JavaScript proceeds to line 7, pushes the log function onto the stack, 'Third' is logged to the console, and the function is popped off the stack.Īt about 4ms, let's say that the file read task is completed in the thread pool. In the background, libuv starts to read the file contents on a separate thread. JavaScript pops off the readFile method from the call stack because its job is done as far as the execution of line 3 is concerned.

Since readFile is an asynchronous operation, it is off-loaded to libuv. At 2ms, the readFile method is pushed onto the stack. At 1ms, 'First' is logged in the console, and the function is popped off the stack. The global function is pushed onto the stack. The main thread of execution always starts in the global scope. In case the native mechanisms are not available or inadequate, it utilizes its thread pool to run the task, ensuring that the main thread is not blocked. Libuv then runs the task using native asynchronous mechanisms of the operating system. Whenever we execute an asynchronous method, libuv takes over the execution of the task. On the right side of the image, we have libuv, which is responsible for handling asynchronous methods. This is a straightforward implementation of the stack data structure, where the last item added is the first one to be removed. When a function returns, it is popped off the call stack. Whenever we declare variables or functions, memory is allocated on the heap, and whenever we execute code, functions are pushed into the call stack. The engine comprises a memory heap and a call stack. When we execute code, the V8 engine, located on the left side of the image, handles the execution of JavaScript code. Let’s conceptualize how code typically executes in the Node runtime.