In layman nodejs--asynchronous I/O

The underlying operating system, asynchronous through the signal volume, message and other ways have a wide range of applications.

The PHP language runs from beginning to end in a synchronous blocking fashion, which facilitates programmers to write business logic sequentially.

asynchronous I/O, event-driven, single-threaded threads make up node's tone.

Why asynchronous I/O

(1), User experience

The asynchronous refresh mechanism is widely used in Web2.0 to improve the user experience and eliminate the blocking of the UI. The back end also employs asynchronous I/O to efficiently request multiple resources at the same time as Max (M,n).

(2), resource allocation

Multi-tasking mainstream approach:

A. Single-threaded asynchronous I/O

B. Multi-threaded parallelism

The cost of multithreading is that the overhead of creating a thread and executing a thread on an afternoon switch is higher. In complex scenes, multithreading often faces problems of lock and State synchronization. However, multithreading can make more efficient use of multicore CPUs and improve utilization.

Nodejs the use of single-line Chengyuan from multi-threaded deadlock, state synchronization and other issues; using asynchronous I/O, let the single-line Chengyuan block to better utilize the CPU.

To compensate for the single-threaded inability to take advantage of multicore CPU features, node uses a child process similar to web workers.

asynchronous I/O

There are only two ways the OS kernel can be I/O: Blocking and non-blocking

A feature of blocking I/O is that the call will not end until after all operations have been completed at the kernel level of the system. It causes the CPU to wait for I/O, wasting time and resources, and insufficient CPU utilization.

The difference between non-blocking I/O is that it returns immediately after the call. The problem is that in order to obtain the complete data, the application needs to repeatedly invoke I/O operations to confirm completion, and this repeated invocation determines whether the completed technique is called polling

Blocking I/O causes the CPU to wait for waste, non-blocking I/O to poll to confirm that the data is fully fetched, CPU processing status, and CPU. There are several main polling technologies:

(1) Read. One of the most primitive inefficiencies, repeated calls to check the status of I/O for complete data reads.

(2) Select. Improved on read by judging the state of the event on the file descriptor. One limitation is that you can check up to 1024 file descriptors at the same time by using a 1024-length array storage state.

(3) poll. The use of linked lists to avoid the limit of the length of the array, and then to avoid unnecessary checks. However, the performance is very low when there are more files.

(4) Epoll. The most efficient I/O event notification mechanism under Linux, when polling is not checked for I/O events, will hibernate until the event has awakened. The actual use of event notifications, the way callbacks are executed, rather than traversing queries. Kequeue and Epoll are similar applications under FreeBSD.

Ideal non-blocking asynchronous I/O

Multithreading simulates ideal non-blocking asynchronous I/O, performing blocking I/O or non-blocking I/OS with a polling technique through partial threads to complete data acquisition, allowing a thread to perform computational processing and passing the data I/O gets through communication between threads.

GLIBC AIO is a typical thread pool that simulates asynchronous I/O, but there are some intolerable flaws that are not recommended.

Libio is an asynchronous I/O library that is re-implemented by the author of Libev, and is still essentially using a thread pool and blocking I/O to emulate asynchronous I/O.

IOCP is an asynchronous I/O scenario for the Windows platform that provides the ideal asynchronous I/O: Calling an async method, waiting for an I/O to complete notification, executing a callback, and the user not having to consider polling. The thread pool principle is still used internally, but the thread pool is managed by the system kernel.

Node provides LIBUV as an abstraction wrapper layer, compatible with Windows platforms and *nix platforms.

node is single threaded, where the single thread is simply referring to JavaScript execution in a single thread. In node, whether it's a Windows or *nix platform, the internal I/O task threads the other thread pool, just transparent to the user. Node itself is multi-threaded, but I/O threads use less CPU, except that user code cannot be executed in parallel, and all I/O is executed in parallel.

Node's asynchronous I/O

Node execution model-event loop

When the process is started, node creates a loop like while (true), and the process of executing a loop body each time is called a tick. Each tick process is to see if there is an event to be processed, and if so, to take out the event and its associated callback function, if there is an associated callback function.

Observers

There is one or more observers in each event loop, and the process of judging whether an event is pending is to ask the observers if there are any events to be handled.

The event loop is a typical producer/consumer model. asynchronous I/O, network requests, and so on, are the producers of events, a stream of different types of events for node, these events are passed to the observer, and the event loop takes the event out of the observer and processes it. Under Windows, this loop is created based on IOCP, while *nix is based on multithreading.

Request Object

There is an intermediate product called the Request object during the transition from JavaScript invocation to the completion of I/O operations by the kernel.

The event loop , the Observer , the request object , and the I/O thread pool together form the basic elements of the node asynchronous I/O model.

Asynchronous API for non-I/O

setTimeout () and setinterval () are used for single-and multiple-tasking tasks, and their created timers are inserted into a red-black tree inside the timer viewer. Each time the tick executes, the timer object is iterated out of the red-black tree to check if it exceeds the timed time, and if the event is exceeded, the callback function executes immediately.

The problem with the timer is that it is not accurate, although the event loop is very fast, but it is possible that the tick execution time is longer.

Process.nexttick () puts the callback function into the queue and takes out execution at the next tick to achieve the settimeout (fn,0) effect, and the more efficient time complexity is O (1) because no red-black trees are needed.

setimmediate () also delays the execution of the callback function, and the callback function in Process.nexttick () takes precedence over Setimmediate (). Since the event loop examines the observer in sequence, Process.nexttick () belongs to the Idle Observer, and Setimmediate () is a check observer, with the following priority: idle Observer >I/O Observer > Check Viewer

The callback function of Process.nexttick () is saved in the array, and each tick executes the callback function in the array, and the callback function of Setimmediate () is saved in the linked list, and each tick executes only one callback function in the list.