Implement blocking instance in nodejs_node.js

The inherent single-threaded programming and callback function asynchronous style in node.js makes us sometimes happy and sometimes worried. Let’s talk about single-threading first. Many people wonder how node.js’s single-thread can achieve high concurrency? This issue is not the focus of this article, so let’s stop there. To clarify, the single thread of node.js only refers to the single-threaded JavaScript engine. In any case, we have no way to implement multi-threading 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 that it cannot be multi-threaded, such as IO. If node.js is now subjected to a large number of requests, and these requests are IO intensive, then every time node accepts a request, the javascript thread will not always wait here when encountering a long IO operation. Instead, hand over control and add the operations to be performed after the IO operation is completed in 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 the stack). During this time, node.js can handle other requests. So for node.js, although javascript is single-threaded and can only process one request at a time, the time it takes for javascript to process a request is often shorter (for IO-intensive applications). As long as it can be processed asynchronously, then in During the processing, this request will release control, allowing node.js to handle other requests. During this concurrent request, IO is actually always in a concurrent state, reducing the number of threads processing requests and saving resources to increase the number of IO threads. For IO-intensive requests that usually take a long time, it will undoubtedly bring performance improvements. promote.

I have been emphasizing IO intensiveness in the past, but I am actually emphasizing the strengths of node.js. Correspondingly, its shortcoming is CPU-intensive requests. The reason is very simple, JavaScript will not be concurrent, and other requests can only be processed after one request is completed. The longer one request takes to process, the longer other requests have to wait. Only one request will be processed at the same time, and the concurrency performance is very low.

Having said that, I want to make it clear: node.js should not be blocked; methods that can be processed asynchronously are processed asynchronously (such as using fs.readFile() instead of fs.syncReadFile() fs.readFileSync() method) .

Cannot be blocked in node, does not mean that it cannot be blocked outside node. We talked about fibers earlier. Now, let’s try to implement blocking in fibers. Let’s take processing an http request as an example:

Copy code The code is as follows:

var Fiber = require('fibers');
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();

For students who are not familiar with the

yield() and run() methods, please check "fibers in node" by yourself.

Fibers do not run in the node process, so blocking within fibers has no impact on the overall performance of the node. And it is quite easy to implement. You only need to yield the fiber when you want to block. If you need to continue running, execute run() to restore the fiber. In the above example, we want to block the current program when the http.get request is initiated, and resume the program when all data reception is completed. So we use Fiber.yield() to interrupt this fiber after calling http.get. In monitoring the response, if the end event is triggered, it indicates that the data transmission is completed, so in the end callback function, call Fiber.current.run() to restore the fiber. In this way, the subsequent code will get http.get in a synchronous manner. Requested data.

The above example is just to provide an idea. If you make some abstract encapsulation of this idea, for example, perform one-step currying on an asynchronous method that accepts a callback function as a parameter, interrupt it after the call, and hijack the callback function to restore the program's code as the callback function. After obtaining the asynchronous data, the program triggers the predetermined callback function, which can basically realize the synchronization of the asynchronous method. This paragraph is quite confusing, but it is basically the implementation idea of ​​fibers/future. If you are interested, please refer to its source code.