Shulou(Shulou.com)06/01 Report--

This article mainly shows you "What are the I/O models in Node", the content is simple and easy to understand, and the organization is clear. I hope it can help you solve your doubts. Let Xiaobian lead you to study and learn "What are the I/O models in Node" this article.

Taking network IO request as an example, we first introduce the typical process of server processing a complete network IO request:

An application obtains an action result, usually consisting of two distinct phases:

Waiting for the data to be ready.

Copy data from kernel to process

Below, we take recvfrom function as an example to explain various IO models.

Block I/O model

A blocking call is when the current thread is suspended until the call result is returned, and the call ends only after the calling thread waits for all operations at the system kernel level to complete.

Blocking I/O causes CPU to wait for I/O, wasting CPU time slices.

Non-blocking I/O model

In contrast to the former, non-blocking I/O returns directly without data, and to retrieve data, it is necessary to try to read the data again through the file descriptor

After the non-blocking call returns (not the actual expected data), the CPU time slice can be used to handle other things, which can significantly improve performance.

But the problem is that the previous operation was not a complete I/O, and the result returned was not the expected business data, but only the asynchronous invocation state.

To get complete data, the application needs to repeatedly invoke IO operations to confirm that the operation has been completed. This operation is called polling. Several common polling strategies are as follows

busy polling

This is the most primitive and least performing way to check I/O status by repeating calls to get complete data

Advantages: Simple programming

Disadvantages: CPU is always spent on polling and affects server performance because the server has to answer after you poll.

I/O multiplexing model

In the I/O reuse model, Select or Poll functions or Epoll functions (supported by Linux kernels after 2.6) are used, which also block processes, but are different from blocking I/O.

These three functions can block multiple I/O operations at the same time, and can detect multiple I/O functions for read operations and write operations at the same time, and do not really call the I/O operation function until there is data readable or writable.

The three I/O multiplexing mechanisms differ as follows

select

Because select stores file state in arrays of length 1024, it can detect up to 1024 file descriptors simultaneously

poll

A slight improvement over select, avoiding the length limit of 1024 with linked lists, and avoiding unnecessary traversal checks, slightly improving performance over select

epoll/kqueue

It is the most efficient I/O event notification mechanism under Linux. If no I/O event is detected during polling, it will sleep until the event occurs to wake up the thread. It really takes advantage of event notifications and performs callbacks rather than traversing (file descriptors) queries, so it doesn't waste CPU

Summary: Essentially, polling is still a synchronous operation because the application is still waiting for I/O to return completely, either traversing the file description state or sleeping for an event to occur.

Signal-driven I/O model

In the signal-driven I/O model, the application uses signals to drive I/O, installs a signal handling function, and the process continues to run without blocking.

When the data is ready, the program receives a SIGIO signal and can call the I/O operation function in the signal processing function to process the data.

Summary: So far, the signal-driven I/O model is more suited to our asynchronous requirements, where programs execute other business logic asynchronously while waiting for data.

But!!! Still blocking data copying from kernel to user space is not a complete revolution (asynchronous).

Ideal (Node) Non-blocking Asynchronous I/O

Our ideal asynchronous I/O should be that the application initiates non-blocking calls, without polling for data acquisition, and there is no need to wait unnecessarily during the data copy phase. Instead, it can be passed to the application through signals or callback functions after the I/O is completed, during which the application can execute other business logic.

Actual asynchronous I/O

In fact, Linux platform natively supports asynchronous I/O (AIO), but AIO is not perfect at present, so I/O reuse model is mainly used when implementing high concurrency network programming under Linux.

In Windows, real asynchronous I/O is implemented through IOCP.

Multithreading emulates asynchronous I/O

Under linux platform, Node uses thread pool to complete data acquisition by letting some threads perform blocking I/O or non-blocking I/O+ polling, and let a single thread perform calculation. Through communication between threads, I/O results are transmitted, thus realizing asynchronous I/O simulation.

In fact, the bottom layer of IOCP asynchronous scheme under Windows platform is also implemented by thread pool, the difference is that the thread pool of the latter is managed by the system kernel.

We often say that Node is single-threaded, but in fact can only say that JS execution in a single thread, whether it is *nix or windows platform, the bottom layer is to use thread pool to complete I/O operations.

That's all for "What are the I/O models in Node?" Thanks for reading! I believe that everyone has a certain understanding, hope to share the content to help everyone, if you still want to learn more knowledge, welcome to pay attention to the industry information channel!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.