In-depth analysis of Node.js asynchronous APIs and their limitations _node.js

The reason for using asynchronous APIs

The concept of asynchrony is first Web2.0 in the browser because JavaScript is executed on a single thread in the browsers. And he also has a common thread to render with the UI. This means that the UI rendering and response is stalled while the JavaScript is executing. For better user experience the asynchronous approach (which, of course, is in the so-called single-threaded language) does not block the main thread from continuing to respond to user actions. This is the category of user experience.

Similarly, if an engineer with other language experience also understands that CPU switching between threads takes a lot of time (mainly between switching and caching between contexts), improving efficiency is also a reason to use asynchronous APIs.

Of course, these are not absolutely correct, but everyone says so. Because if the overhead of creating multithreading is less than parallel execution, the multiple threading approach is preferred, which is often considered a CPU-intensive processing task.

In summary, asynchronous IO or asynchronous APIs can be considered node-specific, because it is a platform for large-scale application-level asynchronous IO applications, which strives to allocate resources more efficiently on a single thread.

About Promise

Here, this article does not intend to explain the use of promise in detail, only a brief description of some promise API and trial scope:

Combine the Fs.readdir function of Nodejs to create a native Promise
var promisetask = new Promise (function (resolve,reject) { 
 fs.readdir ('/ Var/www ', function (err,files) {
   if (!err) {
    resolve (files);
   } else{ 
    reject (err)

;}); Promisetask.then (function (files) { 
 console.log (' content: ' +files ');
 return files; To continue using then to define the next action function after demonstrating another API here return.
Promisetask.catch (function (err) { 
 console.log (' ERROR: ' +err ');
});

How do I wait for multiple promise to complete?

Connect the top
promisetask.then (function (files) { 
 var readfilsepromiselist = Files.map (function (file,index) { return
  new Promise (function (resolve,reject) {
   fs.readfile (file, ' Utf-8 ', function (err,str) {
    if (!err {
     Resolve (str)
    }
    else{
     reject (err)
 }});}); Return Promise.all (readfilsepromiselist);
}). Then (function (Filestrarray) {
 console.log (' so-called file read: ' +filestrarray ');
});

This code does show the elegance of Nodejs development.

So, what's the problem?

Now the elegant language still relies on the operating system, that is to say, the limitations of the system still exist:

I don't know if I can interpret this error as a file operation handle run out, but probably meaning this article wants you to understand that the operating system is not capable of opening an unlimited number of files at the same time.

There is also this:

This is well understood and the memory runs out. Of course, the memory limit can be adjusted by adding the following two run parameters:

Node--max-old-space-size=8192./index.js #单位MB 

The above parameters take effect when V8 is initialized, and are not dynamically changed once they are in effect.

Many people may suggest that the two restrictions exist in other languages as well. Yes, other languages exist.

But other languages have a powerful GC or multithreaded programming model that allows engineers to release the system resources immediately after they apply for it.

While Nodejs can also manually release unwanted system resources, but really can do the reference program in the timely release of every operation?

Give me a chestnut:Nodejs's Redis pack (NPM install Redis) does not provide a synchronized method of operation.

This means that the process of development takes into account more process control, it is a pity that the Nodejs of single-threaded system is not good at this, precisely because there is no concept of multithreading in nature, no locking mechanism, and it is impossible to contain the signal mechanism in the usual sense, the result is that engineers do not know when to manually release resources.

Unless you have absolute control over your project, you do not use any third-party packages that use the asynchronous API.

So, the current conclusion is that promise is just a technique to develop and understand these and not apply to all development scenarios.

Summarize

This is all about the Node.js asynchronous API and its limitations, and hopefully this article will help. If you have any questions, you can exchange messages.