This patch:
- Moves the C++ binding/addon related code out of
node_internals.h/node.cc and into dedicated files
node_binding.h/node_binding.cc, and only puts the code resued
by other files into the header.
- Introduce a node::binding namespace so that code exposed to
other files can be easily recognized.
PR-URL: https://github.com/nodejs/node/pull/24701
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Create a class `PersistentToLocal` which contains three methods,
`Strong`, `Weak`, and `Default`:
* `Strong` returns a `Local` from a strong persistent reference,
* `Weak` returns a `Local` from a weak persistent reference, and
* `Default` decides based on `IsWeak()` which of the above two to call.
These replace `node::StrongPersistentToLocal()`,
`node::WeakPersistentToLocal()`, and `node::PersistentToLocal()`,
respectively.
PR-URL: https://github.com/nodejs/node/pull/24276
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Refael Ackermann <refack@gmail.com>
Move the following code into a new node_errors.cc file and
declare them in node_errors.h for clarity and make it possible
to include them with node_errors.h.
- AppendExceptionLine()
- DecorateErrorStack()
- FatalError()
- OnFatalError()
- PrintErrorString()
- FatalException()
- ReportException()
- FatalTryCatch
And move the following definitions (declared elsewhere than
node_errors.h) to node_errors.cc:
- Abort() (in util.h)
- Assert() (in util.h)
PR-URL: https://github.com/nodejs/node/pull/24058
Reviewed-By: Refael Ackermann <refack@gmail.com>
Reviewed-By: Daniel Bevenius <daniel.bevenius@gmail.com>
Because instances of `napi_env` are created on a per-global-object
basis and because since most N-API functions refer to builtin JS
objects, `napi_env` is essentially in 1:1 correspondence with
`v8::Context`.
This was not clear from the implementation by itself, but has
emerged from conversations with the N-API team.
This patch changes the `napi_env` implementation to:
- Actually store the `v8::Context` it represents.
- Provide more direct access to the `node::Environment`
to which the `Context` belongs.
- Do not store the `uv_loop_t*` explicitly, since it can be
inferred from the `node::Environment` and we actually
have an N-API method for that.
- Replace calls to `isolate->GetCurrentContext()` with
the more appropriate `napi_env` `Context`.
- Implement a better (although not perfect) way of cleaning
up `napi_env` instances.
PR-URL: https://github.com/nodejs/node/pull/23689
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Gus Caplan <me@gus.host>
Reviewed-By: Matheus Marchini <mat@mmarchini.me>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
Make `Environment::GetCurrent()` return `nullptr` if the current
`Context` is not a Node.js context, and for the relevant usage of
this function, either:
- Switch to the better `GetCurrent(args)` variant
- Turn functions in to no-ops where it makes sense
- Make it a `CHECK`, i.e. an API requirement, where it make sense
- Leave a `TODO` comment for verifying what, if anything, is to be done
PR-URL: https://github.com/nodejs/node/pull/22819
Reviewed-By: Gus Caplan <me@gus.host>
Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com>
Reviewed-By: Eugene Ostroukhov <eostroukhov@google.com>
Reviewed-By: Refael Ackermann <refack@gmail.com>
Add `napi_add_finalizer()`, which provides the ability to attach data
to an arbitrary object and be notified when that object is garbage-
collected so as to have an opportunity to delete the data previously
attached.
This differs from `napi_wrap()` in that it does not use up the private
slot on the object, and is therefore neither removable, nor retrievable
after the call to `napi_add_finalizer()`. It is assumed that the data
is accessible by other means, yet it must be tied to the lifetime of
the object. This is the case for data passed to a dynamically created
function which is itself heap-allocated and must therefore be freed
along with the function.
Fixes: https://github.com/nodejs/abi-stable-node/issues/313
PR-URL: https://github.com/nodejs/node/pull/22244
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
Bundle a `uv_async_t`, a `uv_idle_t`, a `uv_mutex_t`, a `uv_cond_t`,
and a `v8::Persistent<v8::Function>` to make it possible to call into JS
from another thread. The API accepts a void data pointer and a callback
which will be invoked on the loop thread and which will receive the
`napi_value` representing the JavaScript function to call so as to
perform the call into JS. The callback is run inside a
`node::CallbackScope`.
A `std::queue<void*>` is used to store calls from the secondary
threads, and an idle loop is started by the `uv_async_t` callback on the
loop thread to drain the queue, calling into JS with each item.
Items can be added to the queue blockingly or non-blockingly.
The thread-safe function can be referenced or unreferenced, with the
same semantics as libuv handles.
Re: https://github.com/nodejs/help/issues/1035
Re: https://github.com/nodejs/node/issues/20964
Fixes: https://github.com/nodejs/node/issues/13512
PR-URL: https://github.com/nodejs/node/pull/17887
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
Added a new struct CallbackBundle to eliminate all
GetInternalField() calls.
The principle is to store all required data inside a C++ struct,
and then store the pointer in the JavaScript object. Before this
change, the required data are stored in the JavaScript object in
3 or 4 seperate pointers. For every napi fun call, 3 of them
have to be fetched out, which are 3 GetInternalField() calls;
after this change, the C++ struct will be directly fetched out
by using v8::External::Value(), which is faster.
Profiling data show that GetInternalField() is slow.
On an i7-4770K (3.50GHz) box, a C++ V8-binding fun call is 8 ns,
before this change, napi fun call is 36 ns; after this change,
napi fun call is 20 ns.
The above data are measured using a modified benchmark in
'benchmark/misc/function_call'. The modification adds an indicator
of the average time of a "chatty" napi fun call (max 50M runs).
This change will speed up chatty case 1.8x (overall), and will cut
down the delay of napi mechanism to approx. 0.5x.
Background: a simple C++ binding function (e.g. receiving little
from JS, doing little and returning little to JS) is called
'chatty' case for JS<-->C++ fun call routine.
This improvement also applies to getter/setter fun calls.
PR-URL: https://github.com/nodejs/node/pull/21072
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Gabriel Schulhof <gabriel.schulhof@intel.com>
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>
Joyee Cheung