AsyncHooks asynchronous life cycle in Node8

Async Hooks is a new feature of Node8. It provides some APIs for tracking the life cycle of asynchronous resources in NodeJs. It is a built-in module of NodeJs and can be directly referenced.

const async_hooks = require('async_hooks');

This is a rarely used module, why does it exist?

We all know that JavaScript was designed as a single-threaded language from the beginning. This is related to its original design intention. The original JavaScript was only used to perform form verification on the page to reduce the time cost of users waiting for server responses in the era of low network speed. With the development of Web front-end technology, although the front-end functions are becoming more and more powerful and more and more important, there seems to be no problem that single-threading cannot solve. In comparison, multi-threading seems to be more complicated, so single-threading is still used today.

Since JavaScript is single-threaded, there are always some time-consuming tasks in daily development, such as timers and the now standardized Ajax. In order to solve these problems, JavaScript divides itself into BOM, DOM, and ECMAScript. BOM will help us solve these time-consuming tasks, which are called asynchronous tasks.

Because the browser's BOM helps us handle asynchronous tasks, most programmers know almost nothing about asynchronous tasks except how to use them. For example, how many asynchronous tasks are in the queue at the same time? We have no way to directly obtain relevant information such as whether the asynchronous process is congested. In many cases, the underlying layer does not require us to pay attention to relevant information. However, if we want relevant information in some cases, NodeJS provides an Experimental API for us to use, which is async_hooks. Why NodeJS? Because only in Node, asynchronous modules such as timers and http can be controlled by developers. The BOM in the browser is not controlled by developers unless the browser provides the corresponding API.

async_hooks rules

async_hooks stipulates that each function will provide a context, which we call an async scope. Each async scope has an asyncId, which is the logo of the current async scope. The asyncId in the same async scope must be the same.

When multiple asynchronous tasks are running in parallel, asyncId allows us to distinguish which asynchronous task to monitor.

asyncId is a self-increasing, non-repeating positive integer. The first asyncId of a program must be 1.

In simple terms, async scope is a synchronous task that cannot be interrupted. As long as it cannot be interrupted, no matter how long the code is, it will share an asyncId. However, if it can be interrupted in the middle, such as a callback or an await in the middle, a new asynchronous context will be created and a new asyncId will be created.

Each async scope has a triggerAsyncId indicating that the current function is triggered by that async scope;

Through asyncId and triggerAsyncId, we can easily track the entire asynchronous call relationship and link.

async_hooks.executionAsyncId() is used to get asyncId. You can see that the global asyncId is 1.

async_hooks.triggerAsyncId() is used to get triggerAsyncId, and its current value is 0.

const async_hooks = require('async_hooks');
console.log('asyncId:', async_hooks.executionAsyncId()); // asyncId: 1
console.log('triggerAsyncId:', async_hooks.triggerAsyncId()); // triggerAsyncId: 0

We use fs.open to open a file here. We can find that the asyncId of fs.open is 7, and the triggerAsyncId of fs.open becomes 1. This is because fs.open is triggered by a global call, and the global asyncId is 1.

const async_hooks = require('async_hooks');
console.log('asyncId:', async_hooks.executionAsyncId()); // asyncId: 1
console.log('triggerAsyncId:', async_hooks.triggerAsyncId()); // triggerAsyncId: 0
const fs = require('fs');
fs.open('./test.js', 'r', (err, fd) => {
    console.log('fs.open.asyncId:', async_hooks.executionAsyncId()); // 7
    console.log('fs.open.triggerAsyncId:', async_hooks.triggerAsyncId()); // 1
});

The life cycle of an asynchronous function

Of course, async_hooks is not used in this way in actual applications. Its correct usage is to trigger callbacks before, after, and after all asynchronous tasks are created, executed, and destroyed, and all callbacks will pass in asyncId.

We can use async_hooks.createHook to create an asynchronous resource hook, which receives an object as a parameter to register some callback functions for events that may occur in the life cycle of asynchronous resources. These hook functions will be triggered every time an asynchronous resource is created/executed/destroyed.

const async_hooks = require('async_hooks');

const asyncHook = async_hooks.createHook({
  init(asyncId, type, triggerAsyncId, resource) { },
  destroy(asyncId) { }
})

Currently, the createHook function can accept five types of Hook Callbacks as follows:

1. init(asyncId, type, triggerAsyncId, resource)

• The init callback function is usually triggered when asynchronous resources are initialized.
• asyncId: Each asynchronous resource will generate a unique identifier
• type: The type of asynchronous resource, usually the name of the resource's constructor.

FSEVENTWRAP, FSREQCALLBACK, GETADDRINFOREQWRAP, GETNAMEINFOREQWRAP, HTTPINCOMINGMESSAGE,
HTTPCLIENTREQUEST, JSSTREAM, PIPECONNECTWRAP, PIPEWRAP, PROCESSWRAP, QUERYWRAP,
SHUTDOWNWRAP, SIGNALWRAP, STATWATCHER, TCPCONNECTWRAP, TCPSERVERWRAP, TCPWRAP,
TTYWRAP, UDPSENDWRAP, UDPWRAP, WRITEWRAP, ZLIB, SSLCONNECTION, PBKDF2REQUEST,
RANDOMBYTESREQUEST, TLSWRAP, Microtask, Timeout, Immediate, TickObject

• triggerAsyncId: indicates the asyncId of the corresponding async scope that triggers the creation of the current asynchronous resource
• resource: represents the asynchronous resource object to be initialized

We can use the async_hooks.createHook function to register listener functions for init/before/after/destory/promiseResolve and other related events that occur in the life cycle of each asynchronous resource;
The same async scope may be called and executed multiple times. No matter how many times it is executed, its asyncId must be the same. Through the monitoring function, we can easily track the number and time of its execution and the relationship with the online context;

2. before(asyncId)

The before function is generally called after the asynchronous resource operation corresponding to asyncId is completed and before the callback is executed. The before callback function may be executed multiple times, which is determined by the number of times it is called back. Please pay attention to this when using it.

3.after(asyncId)

The after callback function is generally called immediately after the asynchronous resource executes the callback function. If an uncaught exception occurs during the execution of the callback function, the after event will be called after the "uncaughtException" event is triggered.

4.destroy(asyncId)

Called when the asynchronous resource corresponding to asyncId is destroyed. The destruction of some asynchronous resources depends on the garbage collection mechanism, so in some cases due to memory leaks, the destroy event may never be triggered.

5. promiseResolve(asyncId)

When the resolve function in the Promise constructor is executed, the promiseResolve event is triggered. In some cases, some resolve functions are executed implicitly, for example, the .then function will return a new Promise, which will also be called at this time.

const async_hooks = require('async_hooks');

// Get the asyncId of the current execution context
const eid = async_hooks.executionAsyncId();

// Get the asyncId that triggers the current function
const tid = async_hooks.triggerAsyncId();

// Create a new AsyncHook instance. All of these callbacks are optional const asyncHook =
    async_hooks.createHook({ init, before, after, destroy, promiseResolve });

//AsyncHook.enable() needs to be declared to execute;

// Disable listening for new asynchronous events.
asyncHook.disable();

function init(asyncId, type, triggerAsyncId, resource) { }

function before(asyncId) { }

function after(asyncId) { }

function destroy(asyncId) { }

function promiseResolve(asyncId) { }

Promises

Promise is a special case. If you are careful enough, you will find that there is no PROMISE in the type of the init method. If you only use ah.executionAsyncId() to get the asyncId of Promise, you cannot get the correct ID. Only after adding the actual hook will async_hooks create an asyncId for the Promise callback.

In other words, since V8 has a high execution cost for obtaining asyncId, by default, we do not assign a new asyncId to Promise.
That is to say, by default, when we use promises or async/await, we cannot get the correct asyncId and triggerId of the current context. But it doesn't matter, we can force the assignment of asyncId to Promise by executing the async_hooks.createHook(callbacks).enable() function.

const async_hooks = require('async_hooks');

const asyncHook = async_hooks.createHook({
  init(asyncId, type, triggerAsyncId, resource) { },
  destroy(asyncId) { }
})

asyncHook.enable();

Promise.resolve(123).then(() => {
  console.log(`asyncId ${async_hooks.executionAsyncId()} triggerId ${async_hooks.triggerAsyncId()}`);
});

In addition, Promise will only trigger the init and promiseResolve hook event functions, and the hook functions of the before and after events will only be triggered when Promise is chained, that is, it will only be triggered when the Promise is generated in the .then/.catch function.

new Promise(resolve => {
    resolve(123);
}).then(data => {
    console.log(data);
})

It can be found that there are two Promises above, the first one is created by new instantiation, and the second one is created by then (if you don’t understand, you can refer to the previous Promise source code article).

The order here is that when executing new Promise, its own init function will be called, and then the promiseResolve function will be called when resolving. Then execute the init function of the second Promise in the then method, and then execute the before, promiseResovle, and after functions of the second Promise.

Exception handling

If an exception occurs in the registered async-hook callback function, the service will print an error log and exit immediately. At the same time, all listeners will be removed and the 'exit' event will be triggered to exit the program.

The reason why the process is exited immediately is that if these async-hook functions run unstably, an exception is likely to be thrown when the next same event is triggered. These functions are mainly used to monitor asynchronous events. If they are unstable, they should be discovered and corrected in time.

Printing logs in asynchronous hook callbacks

Since the console.log function is also an asynchronous call, if we call console.log again in the async-hook function, the corresponding hook event will be triggered again, causing an infinite loop call. Therefore, we must use synchronous logging to track in the async-hook function. We can use the fs.writeSync function:

const fs = require('fs');
const util = require('util');

function debug(...args) {
  fs.writeFileSync('log.out', `${util.format(...args)}\n`, { flag: 'a' });
}

[References - AsyncHooks] (https://nodejs.org/dist/latest-v15.x/docs/api/async_hooks.html)

This is the end of this article about the asynchronous life cycle of AsyncHooks in Node8. For more relevant content about the asynchronous life cycle of Node AsyncHooks, please search for previous articles on 123WORDPRESS.COM or continue to browse the related articles below. I hope you will support 123WORDPRESS.COM in the future!