JavaScript 中的事件循环和 Node.js 中的异步非阻塞 I/O 有什么区别？

Question

. Answers to this question are eligible for a +100 reputation bounty. Flame of udun is looking for a .

In this answer to the question -

What is non-blocking or asynchronous I/O in Node.js?

the description sounds no different from the event loop in vanilla js. Is there a difference between the two? If not, is the Event loop simply re-branded as "Asynchronous non-blocking I/O" to sell Node.js over other options more easily?

Answer 1

The event loop is the mechanism . Asynchronous I/O is the goal .

Asynchronous I/O is a style of programming in which I/O calls do not wait for the operation to complete before returning, but merely arrange for the caller to be notified when that happens, and for the result to be returned somewhere. In JavaScript, the notification is usually performed by invoking a callback or resolving a promise. As far as the programmer is concerned, it doesn't matter how this happens: it just does. I request the operation, and when it's done, I get notified about it.

An event loop is how this is usually achieved. The thing is, in most JavaScript implementations, there is literally a loop somewhere that ultimately boils down to:

while (poll_event(&ev)) {
    dispatch_event(&ev);
}

Performing an asynchronous operation is then done by arranging for the completion of the operation to be received as an event by that loop, and having it dispatch to a callback of the caller's choice.

There are ways to achieve asynchronous programming not based on an event loop, for example using threads and condition variables. But historical reasons make this programming style quite difficult to realise in JavaScript. So in practice, the predominant implementation of asynchrony in JavaScript is based on dispatching callbacks from a global event loop.

From a non-programmer's bird's eye view this may seem like splitting hairs, but the distinction can be occasionally important.

Answer 2

In a traditional Input/Output, when a request comes to a web server, it is assigned to a specific thread. For each concurrent connection, there is a new thread and the thread will continue to run until a response is sent for a particular request. This is a perfect example of Blocking I/O (Input/Output network operation) because when handling a particular request by a thread there will be some idle time when between operations are being performed such as retrieving a file, opening it, reading it, etc.

Each of these thread consumes memory and thus, a thread which runs for a longer period of time and also sits ideally for a significant amount of time in between will definitely consume a lot of memory. This is one of the main reason that the core APIs in Node.js are built in non-blocking way and support asynchronous I/O.

Node.js is itself a runtime environment. It follows an observer pattern (also known as Reactor Pattern in other programming languages) which allows each incoming I/O request to be associated and handle within a function or a handler. This handler function is called a callback function.

At the time of running a Node.js environment, an Event Loop is initialized which handles the I/O operations by offloading them to an operating system's kernel. The different operating system uses different kernels but their basic mechanism of handling an I/O is similar. These kernels are multi threaded and can handle execution of multiple operations in the background. Whenever an I/O operation completes, the Kernel notifies Node.js about it and callback handling that operation will complete its execution.

All of these operations are queued in a poll which is also known as Event Queue. Any of these operations may proceed to more operations and these new operations are then again added to the Event Queue. In summary, Event Loop will always be responsible for the execution of all the asynchronous callbacks registered for every event in the Event Queue.

At the end I wish to conclude that async I/O is just another name of Non-Blocking just to brand Node.js over others. Event loop is re-branded as Async non-blocking I/O.

Answer 3

There are 2 different Event Loops:

1. Browser Event Loop
2. NodeJS Event Loop

Browser Event Loop

The Event Loop is a process that runs continually, executing any task queued. It has multiple task sources which guarantees execution order within that source, but the Browser gets to pick which source to take a task from on each turn of the loop. This allows Browser to give preference to performance sensitive tasks such as user-input.

There are a few different steps that Browser Event Loop checks continuously:

• Task Queue - There can be multiple task queues. Browser can execute queues in any order they like. Tasks in the same queue must be executed in the order they arrived, first in - first out. Tasks execute in order, and the Browser may render between tasks. Task from the same source must go in the same queue. The important thing is that task is going to run from start to finish. After each task, Event Loop will go to Microtask Queue and do all tasks from there.

• Microtasks Queue - The microtask queue is processed at the end of each task. Any additional microtasks queued during during microtasks are added to the end of the queue and are also processed.

• Animation Callback Queue - The animation callback queue is processed before pixels repaint. All animation tasks from the queue will be processed, but any additional animation tasks queued during animation tasks will be scheduled for the next frame.

• Rendering Pipeline - In this step, rendering will happen. The Browser gets to decide when to do this and it tried to be as efficient as possible. The rendering steps only happen if there is something actually worth updating. The majority of screens update at a set frequency, in most cases 60 times a second (60Hz). So, if we would change page style 1000 times a second, rendering steps would not get processed 1000 times a second, but instead it would synchronize itself with the display and only render up to a frequency display is capable of.

Important thing to mention are Web APIs, that are effectively threads. So, for example setTimeout() is an API provided to us by Browser. When you call setTimeout() Web API would take over and process it, and it will return the result to the main thread as a new task in a task queue.

The best video I found that describes how Event Loops works is this one . It helped me a lot when I was investigating how Event Loop works. Another great videos are this one and this one . You should definitely check all of them.

NodeJS Event Loop

NodeJS Event Loop allows NodeJS to perform non-blocking operations by offloading operation to the system kernel whenever possible. Most modern kernels are multi-threaded and they can perform multiple operations in the background. When one of these operations completes, the kernel tells NodeJS.

Library that provides the Event Loop to NodeJS is called Libuv. It will by default create something called Thread Pool with 4 threads to offload asynchronous work to. If you want, you can also change the number of threads in the Thread Pool.

NodeJS Event Loop goes through different phases:

• timers - this phase executes callbacks scheduled by setTimeout() and setInterval() .

• pending callbacks - executes I/O callbacks deferred to the next loop iteration.

• idle, prepare - only used internally.

• poll - retrieve new I/O events; execute I/O related callbacks (almost all with the exception of close callbacks, the ones scheduled by timers, and setImmediate() ) Node will block here when appropriate.

• check - setImmediate() callbacks are invoked here.

• close callbacks - some close callbacks, eg socket.on('close', ...) .

Between each run of the event loop, Node.js checks if it is waiting for any asynchronous I/O or timers and shuts down cleanly if there are not any.

In Browser, we had Web APIs. In NodeJS, we have C++ APIs with the same rule.

I found this video to be useful if you want to check for more information.

Answer 4

• For years, JavaScript has been limited to client-side applications such as interactive web applications that run on the browser. Using NodeJS, JavaScript can be used to develop server-side applications as well. Though it's the same programming language which is used in both use cases, client-side and server-side have different requirements.

• “ Event Loop ” is a generic programming pattern and JavaScript/NodeJS
  event loops are no different. The event loop continuously watches for any queued event handlers and will process them accordingly.

• The “ Events ”, in a browser's context, are user interactions on web
  pages (eg, clicks, mouse movements, keyboard events etc.), but in
  Node's context, events are asynchronous server-side operations (eg, File I/O access, Network I/O etc.)