Anna Henningsen

I think that rules out overhead from the threadpool mechanisms (which is ultimately implemented in a very platform-dependent way). (Btw, file system writes are protected by [a global lock](https://github.com/libuv/libuv/blob/edf05b97f03472def2837ceb2d6bf61a0d0dc248/src/unix/fs.c#L718-L723) on...

> Adding `if (env()->can_call_into_js()) {` around [this code](https://github.com/nodejs/node/blob/6ac55fa337b57cecf36602d0acc3da25ee82a589/src/env-inl.h#L223-L230) solves the async hooks problem I’m not sure what else to do besides doing this and being consistent about this.

@jkrems If the issue is that there are C++ frames in the middle of a stack, cutting it off at some point, I’d prefer to come up with a solution...

@jkrems Right, but I feel like “move code to a different language” is ultimately not a good solution to stack traces not being pretty enough – I’d rather find a...

@jasnell I think in that case you could just use the Node.js version number. I don’t think such a format would be helpful, because we will most likely maintain backwards-compatibility...

I think one reason for this lack of resources might be that for the most part, Node.js is just a ton of glue code that holds libuv, V8, openssl, zlib,...

@hackygolucky Just to be sure we’re talking about the same thing: Are you thinking about a FAQ on Node.js internals, or a FAQ with questions that specifically ask for resources...

> Let me know if it makes sense to implement them here. I’d go with “yes”, for all of these :)

One thing … I think the more common usage of these terms is to call each individual Node major version a “release line”, so the current release lines would be...

How about something like ``` # Node.js releases: Node.js maintains multiple release lines. The most important are… ``` ?