Currently the following warnings are displayed when compiling:
../src/node_api.cc:3380:8:
warning: 'AfterThreadPoolWork' overrides a member function but is not
marked 'override' [-Winconsistent-missing-override]
void AfterThreadPoolWork(int status) {
^
../src/node_internals.h:513:16: note: overridden virtual function is
here
virtual void AfterThreadPoolWork(int status) = 0;
^
1 warning generated.
../src/node_zlib.cc:220:8:
warning: 'DoThreadPoolWork' overrides a member function but is not
marked 'override' [-Winconsistent-missing-override]
void DoThreadPoolWork() {
^
../src/node_internals.h:512:16: note: overridden virtual function is
here
virtual void DoThreadPoolWork() = 0;
^
../src/node_zlib.cc:224:8:
warning: 'AfterThreadPoolWork' overrides a member function but is
not marked 'override' [-Winconsistent-missing-override]
void AfterThreadPoolWork(int status) {
^
../src/node_internals.h:513:16: note: overridden virtual function is
here
virtual void AfterThreadPoolWork(int status) = 0;
^
2 warnings generated.
This commit adds override to the functions.
PR-URL: https://github.com/nodejs/node/pull/20663
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
Instead of using the libuv mechanism directly, provide an internal
`ThreadPoolWork` wrapper that takes care of increasing/decreasing
the waiting request counter.
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 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>
Whenever we call into an addon, whether it is for a callback, for
module init, or for async work-related reasons, we should make sure
that
* the last error is cleared,
* the scopes before the call are the same as after, and
* if an exception was thrown and captured inside the module, then it is
re-thrown after the call.
Therefore we should call into the module in a unified fashion. This
change introduces the macro NAPI_CALL_INTO_MODULE() which should be
used whenever invoking a callback provided by the module.
Fixes: https://github.com/nodejs/node/issues/19437
PR-URL: https://github.com/nodejs/node/pull/19537
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
Replace v8::Persistent with node::Persistent, a specialization that
resets the persistent handle on destruction. Prevents accidental
resource leaks when forgetting to call .Reset() manually.
I'm fairly confident this commit fixes a number of resource leaks that
have gone undiagnosed so far.
PR-URL: https://github.com/nodejs/node/pull/18656
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
According to the ECMA spec, we should throw a RangeError in the
following cases:
- `(length * elementSize) + offset` > the size of the array passed in
- `offset % elementSize` != `0`
In the current implementation, this check was omitted. So, the following
code will cause a crash.
```
napi_create_typedarray(env, napi_uint16_array, 2 /* length */,
buffer, 1 /* byte_offset */, &output_array);
```
This change fixes the problem and write some related tests.
Refs:
https://tc39.github.io/ecma262/#sec-typedarray-buffer-byteoffset-length
PR-URL: https://github.com/nodejs/node/pull/18037
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
Add a utility functions for addons to use when they need
a reference to the current event loop.
While the libuv API is not directly part of N-API, it
provides a quite stable C API as well, and is tightly
integrated with Node itself.
As a particular use case, without access to the event loop
it is hard to do something interesting from inside a N-API
finalizer function, since calls into JS and therefore virtually
all other N-API functions are not allowed.
PR-URL: https://github.com/nodejs/node/pull/17109
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
* namespaced functions such as v8impl::JsHandleScopeFromV8HandleScope
become part of Node's public symbols unless they are declared static.
* the class uvimpl::Work needs to be enclosed in an anonymous namespace
else it, too becomes part of Node's public symbols.
* remove references to EXTERNAL_NAPI.
PR-URL: https://github.com/nodejs/node/pull/16234
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
These changes are necessary in order to retain source compatibility
with older versions of node.
The removal of `module_version` from `napi_module_register()` is
reverted from the flag removal PR, because it should not have been a
part of it.
`CallbackWrapper::NewTarget()` is renamed to
`CallbackWrapper::GetNewTarget()` to distinguish it from V8's native
method, thus allowing for a macro which reduces `NewTarget()` to
`This()` on V8 versions where it was not yet available.
`AsyncResource` is constructed with a C string rather than a V8 string
because the former is available on all versions of node.
PR-URL: https://github.com/nodejs/node/pull/16102
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Jason Ginchereau <jasongin@microsoft.com>
n-api uses size_t for the size of strings when specifying
string lengths. V8 only supports a size of int. Add
a check so that an error will be returned if the user
passes in a string with a size larger than will fit into
an int.
PR-URL: https://github.com/nodejs/node/pull/15611
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Daniel Bevenius <daniel.bevenius@gmail.com>
- Add napi_async_context opaque pointer type.
(If needed, we could later add APIs for getting the async IDs
out of this context.)
- Add napi_async_init() and napi_async_destroy() APIs.
- Add async_context parameter to napi_make_callback().
- Add code and checks to test_make_callback to validate async context
APIs by checking async hooks are called with correct context.
- Update API documentation.
PR-URL: https://github.com/nodejs/node/pull/15189
Fixes: https://github.com/nodejs/node/issues/13254
Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
`node_internals.h` already includes the most common headers,
so double includes can be avoided in a lot of cases. Also don’t include
`node_internals.h` from `node.h` implicitly anymore, as that is mostly
unnecessary.
PR-URL: https://github.com/nodejs/node/pull/14697
Reviewed-By: Tobias Nießen <tniessen@tnie.de>
Reviewed-By: Refael Ackermann <refack@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
The binding testing napi_wrap() creates references to primitives passed
into the binding in its second parameter. This is unnecessary and not
at all the point of the test. Additionally, creating persistent
references to primitive values may not be supported by all VMs, since
primitives are best persisted in their native form.
Instead, the point of the test is to make sure that the finalize
callback gets called when it should get called, that it gets called
with the correct pointer, and that it does not get called when it
should not get called. Creating persistent references is not necessary
for verifying this.
PR-URL: https://github.com/nodejs/node/pull/15289
Reviewed-By: Jason Ginchereau <jasongin@microsoft.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Re: https://github.com/nodejs/node-chakracore/issues/380
Promise is implemented as a pair of objects. `napi_create_promise()`
returns both a JavaScript promise and a newly allocated "deferred" in
its out-params. The deferred is linked to the promise such that the
deferred can be passed to `napi_resolve_deferred()` or
`napi_reject_deferred()` to reject/resolve the promise.
`napi_is_promise()` can be used to check if a `napi_value` is a native
promise - that is, a promise created by the underlying engine, rather
than a pure JS implementation of a promise.
PR-URL: https://github.com/nodejs/node/pull/14365
Fixes: https://github.com/nodejs/abi-stable-node/issues/242
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: Timothy Gu <timothygu99@gmail.com>
Calling napi_wrap() twice on the same object has the result of returning
napi_invalid_arg on the second call. However, sometimes it is necessary
to replace the native pointer associated with a given object. This new
API allows one to remove an existing pointer, returning the object to
its pristine, non-wrapped state.
PR-URL: https://github.com/nodejs/node/pull/14658
Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
Fixes: https://github.com/nodejs/abi-stable-node/issues/266
- Add separate APIs for creating different kinds of numbers,
because creating a V8 number value from an integer is faster
than creating one from a double.
- When getting number values, avoid getting the current context
because the context will not actually be used and is expensive
to obtain.
- When creating values, don't use v8::TryCatch (NAPI_PREAMBLE),
because these functions have no possibility of executing JS code.
Refs: https://github.com/nodejs/node/issues/14379
PR-URL: https://github.com/nodejs/node/pull/14573
Reviewed-By: Timothy Gu <timothygu99@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>