Implement blocking instances in nodejs, while nodejs blocks instances.

Implement blocking instances in nodejs, while nodejs blocks instances.

The inherent single-Thread Programming and asynchronous callback functions in node. js make us sometimes enjoy the worry. First, how can a single thread of node. js achieve high concurrency? This is not the focus of this article. To clarify, node. javascript single thread only means that the javascript engine is single-threaded. In any case, we cannot implement multithreading and blocking in javascript (the method used in this article is also not synchronized through the V8 engine ); but for node. other aspects of js do not mean multithreading, such as IO. If the current node. js suffers from a large number of requests, and these requests are IO-intensive. In this case, each time a node accepts a request, the javascript thread will not wait until it encounters a long IO operation, instead, it refers to the operations to be performed after I/O operations are added to the callback stack (when there are too many callback levels and the number of accesses is too large, a large number of callback chains may burst into the stack ). During this period, node. js can process other requests. So for node. for javascript, although javascript is single-threaded and can only process one request at a time, it usually takes a short time (for IO-intensive applications) to process one request asynchronously, in the processing process, the request will be released to make the node. js can process other requests. At the same time as this concurrent request, I/O has been in the concurrent State, reducing the number of threads processing requests and saving resources to increase the number of I/O threads. For IO-intensive requests that usually take a long time, this will undoubtedly improve the performance.

Previously, I/O-intensive resources were repeatedly emphasized, but node. js strengths were emphasized. Correspondingly, its short board is CPU-intensive requests. The principle is simple. javascript is not concurrent. Only one request can be processed before other requests are processed. The longer a request is processed, the longer the wait time for other requests. At the same time, only one request is processed, and the concurrency performance is very low.

Now, I want to declare one point: node. js should not be blocked; asynchronous processing (such as using fs. readFile (), not fs. syncReadFile () fs. readFileSync () method ).

Node cannot be blocked. It does not mean that it cannot be blocked outside the node. As we have mentioned earlier, we are now trying to implement blocking in the fibers. Let's take an http request as an example:

Copy codeThe Code is as follows:
Var Fiber = require ('scheduler ');
Var http = require ("http ");
Fiber (function (){
Var httpFiber = Fiber. current;
Var html = "";
Http. get ("http://www.baidu.com", function (res ){
Var dataFiber = Fiber. current;
Res. on ("data", function (data ){
Html + = data;
});
Res. on ("end", function (data ){
HttpFiber. run ();
});
});
Fiber. yield ();
Console. log (html );
}). Run ();

If you are not familiar with the yield () and run () methods, please refer to "fiber in node" on your own.

The running of the fibers is not in the node process, so implementing blocking inside the fibers does not affect the overall performance of the node. It is also quite easy to implement. You only need to remove fiber yield when you want to block it. To continue running, run () to restore the fiber. In the preceding example, we want to block the current program when an http. get request is initiated and restore the program when all data is received. Therefore, after http. get is called, Fiber. yield () is used to interrupt the fiber. In the response listener, if the end event is triggered, the data transmission is completed. Therefore, in the end callback function, Fiber is called. current. run () to restore the fiber. In this way, the subsequent code will get http in synchronous mode. get request data.

The above example only provides an idea. If some abstract encapsulation is performed on this idea, for example, one-step curialization is performed on Asynchronous methods that accept callback functions as parameters, and the callback function is interrupted after the call, and the callback function is hijacked, use the code of the restoration program as the callback function. After obtaining asynchronous data, the program triggers the predefined callback function, which basically achieves Asynchronous Method synchronization. This section is messy. It is basically the implementation idea of the fibers/future. If you are interested, please refer to the source code.