This is the final article in this series, covering asynchronous I/O processing in network requests

The first article introduced why we need asynchronous I/O in terms of user experience and resource allocation. This article focuses on asynchronous I/O support at the operating system level.

The second article covered asynchronous I/O support at the operating system level, and the difference between asynchronous and non-blocking.

The third article introduces the implementation of nodeJS asynchronous I/O.

The fourth article introduces the principle of setTimeout, process.nextTick and setImmediate comparison.

Fs.open is an example of an asynchronous I/O request that is processed by an I/O observer.

  1. The operating system kernel listens on ports to receive network requests
  2. Puts the event into the I/O observer queue
  3. An event loop in libuv that asks the I/O observer if there is an event
  4. Execute when an event is found and check to see if there is a callback
  5. A callback function is executed and the controller is transferred to JavaScript

The overall process is similar to the file operation. For a more detailed analysis of the process, see my previous article: juejin.cn/post/700246…

Nodejs was not the first platform to create asynchronous I/O, but it was the first to succeed. Before NodeJS, Ruby, Python and others tried asynchronous I/O, but because they focused on synchronous I/O apis, asynchronous I/O was never developed. Nodejs asynchronous I/O requires no additional overhead of creating and destroying threads, is not affected by the cost of context switching, and has become popular in the community for its outstanding performance benefits.

Nodejs, asynchronous I/O network request, asynchronous I/O network request, asynchronous I/O network request