This adds pairs of methods to the `Environment` class and to public APIs
which can add and remove cleanup handlers.
Unlike `AtExit`, this API targets addon developers rather than
embedders, giving them (and Node’s internals) the ability to register
per-`Environment` cleanup work.
We may want to replace `AtExit` with this API at some point.
Many thanks for Stephen Belanger for reviewing the original version of
this commit in the Ayo.js project.
Refs: https://github.com/ayojs/ayo/pull/82
PR-URL: https://github.com/nodejs/node/pull/19377
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: James M Snell <jasnell@gmail.com>
This fixes a test failure when running
`test/parallel/test-child-process-spawnsync-kill-signal.js`
under load. What would happen is that `SignalExit()` tries
to shutdown the tracing agent, which might not have been set
up by the point that Node.js receives the signal.
PR-URL: https://github.com/nodejs/node/pull/20637
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Tobias Nießen <tniessen@tnie.de>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Removes the requirement to use `--trace-events-enabled` to enable
trace events. Tracing is enabled automatically if there are any
enabled categories.
Adds a new `trace_events` module with an API for enabling/disabling
trace events at runtime without a command line flag.
```js
const trace_events = require('trace_events');
const categories = [ 'node.perf', 'node.async_hooks' ];
const tracing = trace_events.createTracing({ categories });
tracing.enable();
// do stuff
tracing.disable();
```
Multiple `Tracing` objects may exist and be enabled at any point
in time. The enabled trace event categories is the union of all
enabled `Tracing` objects and the `--trace-event-categories`
flag.
PR-URL: https://github.com/nodejs/node/pull/19803
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Ali Ijaz Sheikh <ofrobots@google.com>
Reviewed-By: Franziska Hinkelmann <franziska.hinkelmann@gmail.com>
* Alphabetize the command line options and environment
variables in doc/api/cli.md for consistency and readability.
* Update doc/api/cli.md to include command line options
being printed in the `node.PrintHelp()` function in src/node.cc
but weren't otherwise documented in the cli spec. Options added
include:
--napi-modules
--v8-pool-size=num
--experimental-modules
--experimental-vm-modules
* ASCII sort the node man page command line options.
This change brings sort order consistency between the
cli options displayed in doc/node.1 and the cli options
enumerated in other areas of the project.
Also rearrange the language for `--use-bundled-ca`, `--use-openssl-ca`
to correspond with the order of the options as displayed.
* Update `node.PrintHelp()` function to return command line options
and environment variables sorted in ASCII order. Additionally,
add missing options as sourced from doc/api/cli.md. Options
added include `--`, `--help` and the `NODE_PRESERVE_SYMLINKS`
environment variable.
Also update the comments in the `node.PrintHelp()` method
to C++ style.
* Create tests to validate that the newly ASCII sorted
cli options in the `node.PrintHelp()` function are being
returned according to build configurations as expected.
PR-URL: https://github.com/nodejs/node/pull/19878
Refs: https://github.com/nodejs/node/issues/19814
Reviewed-By: Vse Mozhet Byt <vsemozhetbyt@gmail.com>
Reviewed-By: Khaidi Chu <i@2333.moe>
Reviewed-By: James M Snell <jasnell@gmail.com>
CleanupHandles() has not been called in our own code base anymore
after the v8 debug agent has been removed. It used to be in the
~Environment() destructor but then removed to avoid firing other
events after the exit event, given that we were not going to
clean up handles for the one environment per process setup.
Call it in FreeEnvironment so that embedders can clean up
the handles in the loop when creating multiple environments.
PR-URL: https://github.com/nodejs/node/pull/19319
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Jackson Tian <shyvo1987@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
- Moves the creation of `process.binding()`, `process._linkedBinding()`
`internalBinding()` and `NativeModule` into a separate file
`lib/internal/bootstrap_loaders.js`, and documents them there.
This file will be compiled and run before `bootstrap_node.js`, which
means we now bootstrap the internal module & binding system before
actually bootstrapping Node.js.
- Rename the special ID that can be used to require `NativeModule`
as `internal/bootstrap_loaders` since it is setup there. Also put
`internalBinding` in the object exported by `NativeModule.require`
instead of putting it inside the `NativeModule.wrapper`
- Use the original `getBinding()` to get the source code of native
modules instead of getting it from `process.binding('native')`
so that users cannot fake native modules by modifying the binding
object.
- Names the bootstrapping functions so their names show up
in the stack trace.
PR-URL: https://github.com/nodejs/node/pull/19112
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Anatoli Papirovski <apapirovski@mac.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Gus Caplan <me@gus.host>
This commit set the Environment as a thread local when CreateEnvironment
is called which is currently not being done. This would lead to a
segment fault if later node::AtExit is called without specifying the
environment parameter. This specific issue was reported by Electron.
If I recall correctly, back when this was implemented the motivation was
that if embedders have multiple environments per isolate they should be
using the AtExit functions that take an environment. This is not the
case with Electron which only create a single environment (as far as I
know), and if a native module calls AtExit this would lead to the
segment fault.
I was able to reproduce Electron issue and the provided test simulates
it. I was also able to use this patch and verify that it works for the
Electron issue as well.
PR-URL: https://github.com/nodejs/node/pull/18573
Refs: https://github.com/nodejs/node/pull/9163
Refs: https://github.com/electron/electron/issues/11299
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Matheus Marchini <matheus@sthima.com>
Instead of using nextTick to process failed lists, just attempt to
process them again from C++ if the process is still alive.
This also allows the removal of domain specific code in timers.
The current behaviour is not quite ideal as it means that all lists
after the failed one will process on an arbitrary nextTick, even if
they're — say — not due to fire for another 2 days...
PR-URL: https://github.com/nodejs/node/pull/18486
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: Jeremiah Senkpiel <fishrock123@rocketmail.com>
Up until now, Node did not clear the current error code
attempting to read environment variables on Windows.
Since checking the error code is the way we distinguish between
missing and zero-length environment variables, this could lead to a
false positive when the error code was still tainted.
In the simplest case, accessing a missing variable and then a
zero-length one would lead Node to believe that both calls yielded
an error.
Before:
> process.env.I=''; process.env.Q; process.env.I
undefined
> process.env.I=''; /*process.env.Q;*/ process.env.I
''
After:
> process.env.I=''; process.env.Q; process.env.I
''
> process.env.I=''; /*process.env.Q;*/ process.env.I
''
This only affects Node 8 and above, since before
1aa595e5bd we always constructed a
`v8::String::Value` instance for passing the lookup key to the OS,
which in in turn always made a heap allocation and therefore
reset the error code.
PR-URL: https://github.com/nodejs/node/pull/18463
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Jeremiah Senkpiel <fishrock123@rocketmail.com>
Reviewed-By: Fedor Indutny <fedor.indutny@gmail.com>
Reviewed-By: Tobias Nießen <tniessen@tnie.de>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Tiancheng "Timothy" Gu <timothygu99@gmail.com>
Reviewed-By: Sakthipriyan Vairamani <thechargingvolcano@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
currently if you want to use dynamic import you must use both the
`--experimental-modules` and the `--harmony-dynamic-imports` flags.
Chrome is currently shipping dynamic import unflagged, the flag
only remains in V8 to guard embedders who have not set the appropriate
callback from throwing an unhandled rejection when the feature is used.
As such it is reasonable to enable the flag by default for
`--experimental-modules`
PR-URL: https://github.com/nodejs/node/pull/18387
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Jan Krems <jan.krems@gmail.com>
Reviewed-By: Bradley Farias <bradley.meck@gmail.com>
Reviewed-By: Guy Bedford <guybedford@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Tiancheng "Timothy" Gu <timothygu99@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Currently, both process.binding and internalBinding have to call into
C++ regardless of whether the module has been cached or not. This
creates significant overhead to all binding calls and unfortunately
the rest of the codebase doesn't really optimize the amount of times
that bindings are required (as an example: 12 files require the
async_wrap binding).
Changing all the usage of this function throughout the codebase would
introduce a lot of churn (and is kind of a hassle) so instead this PR
introduces a JS fast path for both functions for cases where the
binding has already been cached. While micro benchmarks are not super
meaningful here (it's not like we call binding that often...), this
does speed up the cached call by 400%.
In addition, move moduleLoadList creation and management entirely into
JS-land as it requires less code and is more efficient.
PR-URL: https://github.com/nodejs/node/pull/18365
Reviewed-By: Tiancheng "Timothy" Gu <timothygu99@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Jeremiah Senkpiel <fishrock123@rocketmail.com>
Move the majority of C++ domain-related code into JS land by introducing
a top level domain callback which handles entering & exiting the domain.
Move the rest of the domain necessities into their own file that creates
an internal binding, to avoid exposing domain-related code on the
process object.
Modify an existing test slightly to better test domain-related code.
PR-URL: https://github.com/nodejs/node/pull/18291
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: James M Snell <jasnell@gmail.com>
Since the `DestroyAsyncIdsCallback` in Node.js can be scheduled as
a result of GC, that means that it can accidentally keep the event
loop open when it shouldn't.
Replace `SetImmediate` with the newly introduced `SetUnrefImmediate`
and in addition introduce RunBeforeExit callbacks, of which
`DestroyAsyncIdsCallback` is now the first. These callbacks will run
before the `beforeExit` event is emitted (which will now only be
emitted if the event loop is still not active).
PR-URL: https://github.com/nodejs/node/pull/18241
Fixes: https://github.com/nodejs/node/issues/18190
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Andreas Madsen <amwebdk@gmail.com>
Remove the unnecessary microTasksTickObject for scheduling microtasks
and instead use TickInfo to keep track of whether promise rejections
exist that need to be emitted. Consequently allow the microtasks to
execute on average fewer times, in more predictable manner than
previously.
Simplify unhandled & handled rejection tracking to do more in C++ to
avoid needing to expose additional info in JS.
When new unhandledRejections are emitted within an unhandledRejection
handler, allow the event loop to proceed first instead. This means
that if the end-user code handles all promise rejections on nextTick,
rejections within unhandledRejection now won't spiral into an infinite
loop.
PR-URL: https://github.com/nodejs/node/pull/18207
Fixes: https://github.com/nodejs/node/issues/17913
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Anna Henningsen