profile
viewpoint
Gabriel Schulhof gabrielschulhof Intel Corporation Santa Clara, California, USA He/Him.

gabrielschulhof/bindings-principles 13

Writing Node.js Bindings - Basic Principles

gabrielschulhof/abi-stable-node-addon-examples 4

Node Add-on Examples with PoC ABI stable API for native modules

gabrielschulhof/jerryscript 2

Ultra-lightweight JavaScript engine for the Internet of Things.

gabrielschulhof/abi-stable-node 0

Node with PoC ABI stable API for native modules

gabrielschulhof/aes-js 0

A pure JavaScript implementation of the AES block cipher and all common modes of operation for node.js or web browsers.

gabrielschulhof/api.jquerymobile.com 0

API documentation for jQuery Mobile

gabrielschulhof/apt-source-whitelist 0

Whitelist of apt sources approved for build environments with restricted sudo

gabrielschulhof/bleno 0

A Node.js module for implementing BLE (Bluetooth Low Energy) peripherals

gabrielschulhof/browser-perf-runner 0

Run browser-perf on websites

issue commentnodejs/node

We should not expose the void* coming in via the async cleanup hook to the add-on

It should be OK to make this change because the async cleanup hooks APIs are still NAPI_EXPERIMENTAL.

gabrielschulhof

comment created time in 2 days

issue commentnodejs/node

We should not expose the void* coming in via the async cleanup hook to the add-on

@addaleax, please correct me if I'm wrong!

gabrielschulhof

comment created time in 2 days

issue openednodejs/node

We should not expose the void* coming in via the async cleanup hook to the add-on

At

https://github.com/nodejs/node/blob/bcfb1762a3e613e71ac68ab8a6420e2f33c0f603/src/node_api.h#L257

cbarg is a pointer passing from the core into the add-on. The core expects that it will be passed back into the core as the first parameter to cb. There is no guarantee that add-on authors will faithfully pass it back as expected.

We should create a wrapper that retains cbarg in the implementation, making it possible to give a function `void (*cb)() to the add-on.

created time in 2 days

pull request commentnodejs/node

n-api: fix use-after-free with napi_remove_async_cleanup_hook

Shall we fast-track, given that this is breaking the CI?

addaleax

comment created time in 5 days

pull request commentnodejs/node

n-api,src: provide asynchronous cleanup hooks

@addaleax the libasan heap-use-after-free github actions test failure seemed legit what with napi_remove_async_cleanup_hook in the stack.

addaleax

comment created time in 5 days

pull request commentnodejs/node-addon-api

src: concentrate callbacks provided to core N-API

CI:

Version Job Status
v15.x https://ci.nodejs.org/job/node-test-node-addon-api-new/2596/
v14.x https://ci.nodejs.org/job/node-test-node-addon-api-new/2597/
v12.x https://ci.nodejs.org/job/node-test-node-addon-api-new/2598/
v10.x https://ci.nodejs.org/job/node-test-node-addon-api-new/2599/
gabrielschulhof

comment created time in 5 days

PR opened nodejs/node-addon-api

src: concentrate callbacks provided to core N-API

This change reduces the places where we declare private functions with the napi_callback signature for the purpose of using them with C++ callbacks passed as template arguments. We basically have 4 types:

  1. static with void return
  2. static with napi_value return
  3. instance with void return
  4. instance with napi_value return

We can use one of these four calling patterns in the following places where we accept callbacks as template arguments:

  • Napi::Function (1. and 2.)
  • Napi::PropertyDescriptor (1. for the setter, 2. for the getter)
  • Napi::InstanceWrap<T> (3., 4. for instance methods, 4. for instance getters)
  • Napi::ObjectWrap<T> (1., 2. for static methods, 2. for static getters)

In the case of InstanceWrap<T> and ObjectWrap<T> instance resp. static property descriptors we can also remove the infrastructure designed to allow for optional getters (GetterTag resp. StaticGetterTag) because the API for specifying instance resp. class property descriptors does not allow one to omit the getter.

Signed-off-by: @gabrielschulhof

+72 -113

0 comment

2 changed files

pr created time in 5 days

push eventgabrielschulhof/node-addon-api

Gabriel Schulhof

commit sha 2842eada6505f6d7751f04dd6afb7b825c0c6567

src: concentrate callbacks provided to core N-API This change reduces the places where we declare private functions with the `napi_callback` signature for the purpose of using them with C++ callbacks passed as template arguments. We basically have 4 types: 1. static with `void` return 2. static with `napi_value` return 3. instance with `void` return 4. instance with `napi_value` return We can use one of these four calling patterns in the following places where we accept callbacks as template arguments: * `Napi::Function` (1. and 2.) * `Napi::PropertyDescriptor` (1. for the setter, 2. for the getter) * `Napi::InstanceWrap<T>` (3., 4. for instance methods, 4. for instance getters) * `Napi::ObjectWrap<T>` (1., 2. for static methods, 2. for static getters) In the case of `InstanceWrap<T>` and `ObjectWrap<T>` instance resp. static property descriptors we can also remove the infrastructure designed to allow for optional getters (`GetterTag` resp. `StaticGetterTag`) because the API for specifying instance resp. class property descriptors does not allow one to omit the getter. Signed-off-by: Gabriel Schulhof <gabriel.schulhof@intel.com>

view details

push time in 5 days

push eventgabrielschulhof/node-addon-api

Gabriel Schulhof

commit sha 2842eada6505f6d7751f04dd6afb7b825c0c6567

src: concentrate callbacks provided to core N-API This change reduces the places where we declare private functions with the `napi_callback` signature for the purpose of using them with C++ callbacks passed as template arguments. We basically have 4 types: 1. static with `void` return 2. static with `napi_value` return 3. instance with `void` return 4. instance with `napi_value` return We can use one of these four calling patterns in the following places where we accept callbacks as template arguments: * `Napi::Function` (1. and 2.) * `Napi::PropertyDescriptor` (1. for the setter, 2. for the getter) * `Napi::InstanceWrap<T>` (3., 4. for instance methods, 4. for instance getters) * `Napi::ObjectWrap<T>` (1., 2. for static methods, 2. for static getters) In the case of `InstanceWrap<T>` and `ObjectWrap<T>` instance resp. static property descriptors we can also remove the infrastructure designed to allow for optional getters (`GetterTag` resp. `StaticGetterTag`) because the API for specifying instance resp. class property descriptors does not allow one to omit the getter. Signed-off-by: Gabriel Schulhof <gabriel.schulhof@intel.com>

view details

Gabriel Schulhof

commit sha 66a3b74ccb2b72cd18f34d18a0cf5eca5bb64e33

Use NAPI_NOEXCEPT elsewhere

view details

push time in 5 days

delete branch gabrielschulhof/node-addon-api

delete branch : async-tests

delete time in 5 days

delete branch gabrielschulhof/node-addon-api

delete branch : addon-instance-data-idempotent

delete time in 5 days

delete branch gabrielschulhof/node-addon-api

delete branch : addon-instance-data

delete time in 5 days

delete branch gabrielschulhof/node-addon-api

delete branch : addon-class

delete time in 5 days

delete branch gabrielschulhof/node-addon-api

delete branch : add-templated-function-benchmark

delete time in 5 days

create barnchgabrielschulhof/node-addon-api

branch : use-NAPI_NOEXCEPT-consistently

created branch time in 5 days

delete branch gabrielschulhof/node-addon-api

delete branch : add-instance-data-doc

delete time in 6 days

delete branch gabrielschulhof/node-addon-api

delete branch : make-sure-wrapcallback-is-used

delete time in 6 days

push eventgabrielschulhof/node-addon-api

Gabriel Schulhof

commit sha cec2c769417b476711ce5f5fe95e9e6cddb9a529

src: wrap finalizer callback Make sure C++ exceptions thrown from a finalizer are converted into JS exceptions just as they are in regular callbacks. Signed-off-by: Gabriel Schulhof <gabriel.schulhof@intel.com> PR-URL: https://github.com/nodejs/node-addon-api/pull/762 Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com> test: add finalizer exception test src: wrap finalizer callback

view details

push time in 6 days

PR closed nodejs/node-addon-api

Reviewers
Make sure wrapcallback is used

Finalizers are also able to call JS code and therefore throw. Thus, when calling the user's finalizer, we should wrap it in our C++-to-JS-exception converter.

+94 -11

8 comments

3 changed files

gabrielschulhof

pr closed time in 6 days

pull request commentnodejs/node-addon-api

Make sure wrapcallback is used

Landed in cec2c769417b476711ce5f5fe95e9e6cddb9a529.

gabrielschulhof

comment created time in 6 days

push eventnodejs/node-addon-api

Gabriel Schulhof

commit sha cec2c769417b476711ce5f5fe95e9e6cddb9a529

src: wrap finalizer callback Make sure C++ exceptions thrown from a finalizer are converted into JS exceptions just as they are in regular callbacks. Signed-off-by: Gabriel Schulhof <gabriel.schulhof@intel.com> PR-URL: https://github.com/nodejs/node-addon-api/pull/762 Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com> test: add finalizer exception test src: wrap finalizer callback

view details

push time in 6 days

pull request commentnodejs/node-addon-api

Make sure wrapcallback is used

New CI:

Version Job Status
v15.x https://ci.nodejs.org/job/node-test-node-addon-api-new/2592/
v14.x https://ci.nodejs.org/job/node-test-node-addon-api-new/2593/
v12.x https://ci.nodejs.org/job/node-test-node-addon-api-new/2594/
v10.x https://ci.nodejs.org/job/node-test-node-addon-api-new/2595/
gabrielschulhof

comment created time in 6 days

Pull request review commentnodejs/node-addon-api

tsfn: implement ThreadSafeFunctionEx

+# ThreadSafeFunctionEx++The `Napi::ThreadSafeFunctionEx` type provides APIs for threads to communicate+with the addon's main thread to invoke JavaScript functions on their behalf. The+type is a three-argument templated class, each argument representing the type+of:+- `ContextType = std::nullptr_t`: The thread-safe function's context. By default,+  a TSFN has no context.+- `DataType = void*`: The data to use in the native callback. By default, a TSFN+  can accept *any* data type.+- `Callback = void*(Napi::Env, Napi::Function jsCallback, ContextType*,+  DataType*)`: The callback to run for each item added to the queue. If no+  `Callback` is given, the API will call the function `jsCallback` with no+  arguments.++Documentation can be found for an [overview of the API](threadsafe.md), as well+as [differences between the two thread-safe function+APIs](threadsafe.md#implementation-differences).++## Methods++### Constructor++Creates a new empty instance of `Napi::ThreadSafeFunctionEx`.++```cpp+Napi::Function::ThreadSafeFunctionEx<ContextType, DataType, Callback>::ThreadSafeFunctionEx();+```++### Constructor++Creates a new instance of the `Napi::ThreadSafeFunctionEx` object.++```cpp+Napi::ThreadSafeFunctionEx<ContextType, DataType, Callback>::ThreadSafeFunctionEx(napi_threadsafe_function tsfn);+```++- `tsfn`: The `napi_threadsafe_function` which is a handle for an existing+  thread-safe function.++Returns a non-empty `Napi::ThreadSafeFunctionEx` instance. To ensure the API+statically handles the correct return type for `GetContext()` and+`[Non]BlockingCall()`, pass the proper type arguments to+`Napi::ThreadSafeFunctionEx`.++### New++Creates a new instance of the `Napi::ThreadSafeFunctionEx` object. The `New`+function has several overloads for the various optional parameters: skip the+optional parameter for that specific overload.++```cpp+New(napi_env env,+    CallbackType callback,+    const Object& resource,+    ResourceString resourceName,+    size_t maxQueueSize,+    size_t initialThreadCount,+    ContextType* context,+    Finalizer finalizeCallback,+    FinalizerDataType* data = nullptr);+```++- `env`: The `napi_env` environment in which to construct the+  `Napi::ThreadSafeFunction` object.+- `[optional] callback`: The `Function` to call from another thread.+- `[optional] resource`: An object associated with the async work that will be+  passed to possible async_hooks init hooks.+- `resourceName`: A JavaScript string to provide an identifier for the kind of+  resource that is being provided for diagnostic information exposed by the+  async_hooks API.+- `maxQueueSize`: Maximum size of the queue. `0` for no limit.+- `initialThreadCount`: The initial number of threads, including the main+  thread, which will be making use of this function.+- `[optional] context`: Data to attach to the resulting `ThreadSafeFunction`.+  Can be retreived via `GetContext()`.+- `[optional] finalizeCallback`: Function to call when the+  `ThreadSafeFunctionEx` is being destroyed.  This callback will be invoked on+  the main thread when the thread-safe function is about to be destroyed. It+  receives the context and the finalize data given during construction (if+  given), and provides an opportunity for cleaning up after the threads e.g. by+  calling `uv_thread_join()`. It is important that, aside from the main loop+  thread, there be no threads left using the thread-safe function after the+  finalize callback completes. Must implement `void operator()(Env env,+  DataType* data, ContextType* hint)`.+- `[optional] data`: Data to be passed to `finalizeCallback`.++Returns a non-empty `Napi::ThreadSafeFunctionEx` instance.++Depending on the targetted `NAPI_VERSION`, the API has different implementations+for `CallbackType callback`.++When targetting version 4, `CallbackType` is:+- `const Function&`+- skipped, in which case the API creates a new no-op `Function`++When targetting version 5+, `CallbackType` is:+- `const Function&`+- `std::nullptr_t`+- skipped, in which case the API passes `std::nullptr`

This is unclear, especially how the word "skipped" fits in. Is this supposed to mean "When targetting version <x> and CallbackType is skipped..."?

KevinEady

comment created time in 6 days

Pull request review commentnodejs/node-addon-api

tsfn: implement ThreadSafeFunctionEx

+# ThreadSafeFunctionEx++The `Napi::ThreadSafeFunctionEx` type provides APIs for threads to communicate+with the addon's main thread to invoke JavaScript functions on their behalf. The+type is a three-argument templated class, each argument representing the type+of:+- `ContextType = std::nullptr_t`: The thread-safe function's context. By default,+  a TSFN has no context.+- `DataType = void*`: The data to use in the native callback. By default, a TSFN+  can accept *any* data type.+- `Callback = void*(Napi::Env, Napi::Function jsCallback, ContextType*,
- `Callback = void(*)(Napi::Env, Napi::Function jsCallback, ContextType*,
KevinEady

comment created time in 6 days

Pull request review commentnodejs/node-addon-api

tsfn: implement ThreadSafeFunctionEx

 New(napi_env env, - `initialThreadCount`: The initial number of threads, including the main   thread, which will be making use of this function. - `[optional] context`: Data to attach to the resulting `ThreadSafeFunction`.+  Can be retreived via `GetContext()`.
  It can be retreived by calling `GetContext()`.

Maybe make GetContext() a link?

KevinEady

comment created time in 6 days

Pull request review commentnodejs/node-addon-api

tsfn: implement ThreadSafeFunctionEx

+# ThreadSafeFunctionEx++The `Napi::ThreadSafeFunctionEx` type provides APIs for threads to communicate+with the addon's main thread to invoke JavaScript functions on their behalf. The+type is a three-argument templated class, each argument representing the type+of:+- `ContextType = std::nullptr_t`: The thread-safe function's context. By default,+  a TSFN has no context.+- `DataType = void*`: The data to use in the native callback. By default, a TSFN+  can accept *any* data type.+- `Callback = void*(Napi::Env, Napi::Function jsCallback, ContextType*,+  DataType*)`: The callback to run for each item added to the queue. If no+  `Callback` is given, the API will call the function `jsCallback` with no+  arguments.++Documentation can be found for an [overview of the API](threadsafe.md), as well+as [differences between the two thread-safe function+APIs](threadsafe.md#implementation-differences).++## Methods++### Constructor++Creates a new empty instance of `Napi::ThreadSafeFunctionEx`.++```cpp+Napi::Function::ThreadSafeFunctionEx<ContextType, DataType, Callback>::ThreadSafeFunctionEx();+```++### Constructor++Creates a new instance of the `Napi::ThreadSafeFunctionEx` object.++```cpp+Napi::ThreadSafeFunctionEx<ContextType, DataType, Callback>::ThreadSafeFunctionEx(napi_threadsafe_function tsfn);+```++- `tsfn`: The `napi_threadsafe_function` which is a handle for an existing+  thread-safe function.++Returns a non-empty `Napi::ThreadSafeFunctionEx` instance. To ensure the API+statically handles the correct return type for `GetContext()` and+`[Non]BlockingCall()`, pass the proper type arguments to+`Napi::ThreadSafeFunctionEx`.++### New++Creates a new instance of the `Napi::ThreadSafeFunctionEx` object. The `New`+function has several overloads for the various optional parameters: skip the+optional parameter for that specific overload.++```cpp+New(napi_env env,+    CallbackType callback,+    const Object& resource,+    ResourceString resourceName,+    size_t maxQueueSize,+    size_t initialThreadCount,+    ContextType* context,+    Finalizer finalizeCallback,+    FinalizerDataType* data = nullptr);+```++- `env`: The `napi_env` environment in which to construct the+  `Napi::ThreadSafeFunction` object.+- `[optional] callback`: The `Function` to call from another thread.+- `[optional] resource`: An object associated with the async work that will be+  passed to possible async_hooks init hooks.+- `resourceName`: A JavaScript string to provide an identifier for the kind of+  resource that is being provided for diagnostic information exposed by the+  async_hooks API.+- `maxQueueSize`: Maximum size of the queue. `0` for no limit.+- `initialThreadCount`: The initial number of threads, including the main+  thread, which will be making use of this function.+- `[optional] context`: Data to attach to the resulting `ThreadSafeFunction`.+  Can be retreived via `GetContext()`.
  It can be retreived via `GetContext()`.
KevinEady

comment created time in 6 days

Pull request review commentnodejs/node-addon-api

tsfn: implement ThreadSafeFunctionEx

+# Thread-safe Functions++JavaScript functions can normally only be called from a native addon's main+thread. If an addon creates additional threads, then node-addon-api functions+that require a `Napi::Env`, `Napi::Value`, or `Napi::Reference` must not be+called from those threads.++When an addon has additional threads and JavaScript functions need to be invoked+based on the processing completed by those threads, those threads must+communicate with the addon's main thread so that the main thread can invoke the+JavaScript function on their behalf. The thread-safe function APIs provide an+easy way to do this. These APIs provide two types --+[`Napi::ThreadSafeFunction`](threadsafe_function.md) and+[`Napi::ThreadSafeFunctionEx`](threadsafe_function_ex.md) -- as well as APIs to+create, destroy, and call objects of this type. The differences between the two+are subtle and are [highlighted below](#implementation-differences). Regardless+of which type you choose, the API between the two are similar.++`Napi::ThreadSafeFunction[Ex]::New()` creates a persistent reference that holds+a JavaScript function which can be called from multiple threads. The calls+happen asynchronously. This means that values with which the JavaScript callback+is to be called will be placed in a queue, and, for each value in the queue, a+call will eventually be made to the JavaScript function.++`Napi::ThreadSafeFunction[Ex]` objects are destroyed when every thread which+uses the object has called `Release()` or has received a return status of+`napi_closing` in response to a call to `BlockingCall()` or `NonBlockingCall()`.+The queue is emptied before the `Napi::ThreadSafeFunction[Ex]` is destroyed. It+is important that `Release()` be the last API call made in conjunction with a+given `Napi::ThreadSafeFunction[Ex]`, because after the call completes, there is+no guarantee that the `Napi::ThreadSafeFunction[Ex]` is still allocated. For the+same reason it is also important that no more use be made of a thread-safe+function after receiving a return value of `napi_closing` in response to a call+to `BlockingCall()` or `NonBlockingCall()`. Data associated with the+`Napi::ThreadSafeFunction[Ex]` can be freed in its `Finalizer` callback which+was passed to `ThreadSafeFunction[Ex]::New()`.++Once the number of threads making use of a `Napi::ThreadSafeFunction[Ex]`+reaches zero, no further threads can start making use of it by calling+`Acquire()`. In fact, all subsequent API calls associated with it, except+`Release()`, will return an error value of `napi_closing`.++## Implementation Differences++The choice between `Napi::ThreadSafeFunction` and `Napi::ThreadSafeFunctionEx`+depends largely on how you plan to execute your native C++ code (the "callback")+on the Node thread.++### [`Napi::ThreadSafeFunction`](threadsafe_function.md)++This API is designed without N-API 5 native support for [optional JavaScript+  function callback feature](https://github.com/nodejs/node/commit/53297e66cb).+  `::New` methods that do not have a `Function` parameter will construct a+  _new_, no-op `Function` on the environment to pass to the underlying N-API+  call.++This API has some dynamic functionality, in that:+- The `[Non]BlockingCall()` methods provide a `Napi::Function` parameter as the+  callback to run when processing the data item on the main thread -- the+  `CallJs` callback. Since the callback is a parameter, it can be changed for+  every call.+- Different C++ data types may be passed with each call of `[Non]BlockingCall()`+  to match the specific data type as specified in the `CallJs` callback.++However, this functionality comes with some **additional overhead** and+situational **memory leaks**:+- The API acts as a "middle-man" between the underlying+  `napi_threadsafe_function`, and dynamically constructs a wrapper for your+  callback on the heap for every call to `[Non]BlockingCall()`.+- In acting in this "middle-man" fashion, the API will call the underlying "make+  call" N-API method on this packaged item. If the API has determined the+  thread-safe function is no longer accessible (eg. all threads have released yet+  there are still items on the queue), **the callback passed to+  [Non]BlockingCall will not execute**. This means it is impossible to perform+  clean-up for calls that never execute their `CallJs` callback. **This may lead+  to memory leaks** if you are dynamically allocating memory.+- The `CallJs` does not receive the thread-safe function's context as a+  parameter. In order for the callback to access the context, it must have a+  reference to either (1) the context directly, or (2) the thread-safe function+  to call `GetContext()`. Furthermore, the `GetContext()` method is not+  _type-safe_, as the method returns an object that can be "any-casted", instead+  of having a static type.++### [`Napi::ThreadSafeFunctionEx`](threadsafe_function_ex.md)++The `ThreadSafeFunctionEx` class is a new implementation to address the+drawbacks listed above. The API is designed with N-API 5's support of an+optional function callback. The API will correctly allow developers to pass+`std::nullptr` instead of a `const Function&` for the callback function+specified in `::New`. It also provides helper APIs to _target_ N-API 4 and+construct a no-op `Function` **or** to target N-API 5 and "construct" an+`std::nullptr` callback. This allows a single codebase to use the same APIs,+with just a switch of the `NAPI_VERSION` compile-time constant.++The removal of the dynamic call functionality has the additional side effects:+- The API does _not_ act as a "middle-man" compared to the non-`Ex`. Once Node+  finalizes the thread-safe function, the `CallJs` callback will execute with an+  empty `Napi::Env` for any remaining items on the queue. This provides the the+  ability to handle any necessary clean up of the item's data.
  ability to handle any necessary cleanup of the item's data.
KevinEady

comment created time in 6 days

Pull request review commentnodejs/node-addon-api

tsfn: implement ThreadSafeFunctionEx

+# Thread-safe Functions++JavaScript functions can normally only be called from a native addon's main+thread. If an addon creates additional threads, then node-addon-api functions+that require a `Napi::Env`, `Napi::Value`, or `Napi::Reference` must not be+called from those threads.++When an addon has additional threads and JavaScript functions need to be invoked+based on the processing completed by those threads, those threads must+communicate with the addon's main thread so that the main thread can invoke the+JavaScript function on their behalf. The thread-safe function APIs provide an+easy way to do this. These APIs provide two types --+[`Napi::ThreadSafeFunction`](threadsafe_function.md) and+[`Napi::ThreadSafeFunctionEx`](threadsafe_function_ex.md) -- as well as APIs to+create, destroy, and call objects of this type. The differences between the two+are subtle and are [highlighted below](#implementation-differences). Regardless+of which type you choose, the API between the two are similar.++`Napi::ThreadSafeFunction[Ex]::New()` creates a persistent reference that holds+a JavaScript function which can be called from multiple threads. The calls+happen asynchronously. This means that values with which the JavaScript callback+is to be called will be placed in a queue, and, for each value in the queue, a+call will eventually be made to the JavaScript function.++`Napi::ThreadSafeFunction[Ex]` objects are destroyed when every thread which+uses the object has called `Release()` or has received a return status of+`napi_closing` in response to a call to `BlockingCall()` or `NonBlockingCall()`.+The queue is emptied before the `Napi::ThreadSafeFunction[Ex]` is destroyed. It+is important that `Release()` be the last API call made in conjunction with a+given `Napi::ThreadSafeFunction[Ex]`, because after the call completes, there is+no guarantee that the `Napi::ThreadSafeFunction[Ex]` is still allocated. For the+same reason it is also important that no more use be made of a thread-safe+function after receiving a return value of `napi_closing` in response to a call+to `BlockingCall()` or `NonBlockingCall()`. Data associated with the+`Napi::ThreadSafeFunction[Ex]` can be freed in its `Finalizer` callback which+was passed to `ThreadSafeFunction[Ex]::New()`.++Once the number of threads making use of a `Napi::ThreadSafeFunction[Ex]`+reaches zero, no further threads can start making use of it by calling+`Acquire()`. In fact, all subsequent API calls associated with it, except+`Release()`, will return an error value of `napi_closing`.++## Implementation Differences++The choice between `Napi::ThreadSafeFunction` and `Napi::ThreadSafeFunctionEx`+depends largely on how you plan to execute your native C++ code (the "callback")+on the Node thread.++### [`Napi::ThreadSafeFunction`](threadsafe_function.md)++This API is designed without N-API 5 native support for [optional JavaScript+  function callback feature](https://github.com/nodejs/node/commit/53297e66cb).+  `::New` methods that do not have a `Function` parameter will construct a+  _new_, no-op `Function` on the environment to pass to the underlying N-API+  call.++This API has some dynamic functionality, in that:+- The `[Non]BlockingCall()` methods provide a `Napi::Function` parameter as the+  callback to run when processing the data item on the main thread -- the+  `CallJs` callback. Since the callback is a parameter, it can be changed for+  every call.+- Different C++ data types may be passed with each call of `[Non]BlockingCall()`+  to match the specific data type as specified in the `CallJs` callback.++However, this functionality comes with some **additional overhead** and+situational **memory leaks**:+- The API acts as a "middle-man" between the underlying+  `napi_threadsafe_function`, and dynamically constructs a wrapper for your+  callback on the heap for every call to `[Non]BlockingCall()`.+- In acting in this "middle-man" fashion, the API will call the underlying "make+  call" N-API method on this packaged item. If the API has determined the+  thread-safe function is no longer accessible (eg. all threads have released yet+  there are still items on the queue), **the callback passed to+  [Non]BlockingCall will not execute**. This means it is impossible to perform+  clean-up for calls that never execute their `CallJs` callback. **This may lead+  to memory leaks** if you are dynamically allocating memory.+- The `CallJs` does not receive the thread-safe function's context as a+  parameter. In order for the callback to access the context, it must have a+  reference to either (1) the context directly, or (2) the thread-safe function+  to call `GetContext()`. Furthermore, the `GetContext()` method is not+  _type-safe_, as the method returns an object that can be "any-casted", instead+  of having a static type.++### [`Napi::ThreadSafeFunctionEx`](threadsafe_function_ex.md)++The `ThreadSafeFunctionEx` class is a new implementation to address the+drawbacks listed above. The API is designed with N-API 5's support of an+optional function callback. The API will correctly allow developers to pass+`std::nullptr` instead of a `const Function&` for the callback function+specified in `::New`. It also provides helper APIs to _target_ N-API 4 and+construct a no-op `Function` **or** to target N-API 5 and "construct" an+`std::nullptr` callback. This allows a single codebase to use the same APIs,+with just a switch of the `NAPI_VERSION` compile-time constant.++The removal of the dynamic call functionality has the additional side effects:+- The API does _not_ act as a "middle-man" compared to the non-`Ex`. Once Node+  finalizes the thread-safe function, the `CallJs` callback will execute with an+  empty `Napi::Env` for any remaining items on the queue. This provides the the
  empty `Napi::Env` for any remaining items on the queue. This provides the
KevinEady

comment created time in 6 days

Pull request review commentnodejs/node-addon-api

tsfn: implement ThreadSafeFunctionEx

+# Thread-safe Functions++JavaScript functions can normally only be called from a native addon's main+thread. If an addon creates additional threads, then node-addon-api functions+that require a `Napi::Env`, `Napi::Value`, or `Napi::Reference` must not be+called from those threads.++When an addon has additional threads and JavaScript functions need to be invoked+based on the processing completed by those threads, those threads must+communicate with the addon's main thread so that the main thread can invoke the+JavaScript function on their behalf. The thread-safe function APIs provide an+easy way to do this. These APIs provide two types --+[`Napi::ThreadSafeFunction`](threadsafe_function.md) and+[`Napi::ThreadSafeFunctionEx`](threadsafe_function_ex.md) -- as well as APIs to+create, destroy, and call objects of this type. The differences between the two+are subtle and are [highlighted below](#implementation-differences). Regardless+of which type you choose, the API between the two are similar.++`Napi::ThreadSafeFunction[Ex]::New()` creates a persistent reference that holds+a JavaScript function which can be called from multiple threads. The calls+happen asynchronously. This means that values with which the JavaScript callback+is to be called will be placed in a queue, and, for each value in the queue, a+call will eventually be made to the JavaScript function.++`Napi::ThreadSafeFunction[Ex]` objects are destroyed when every thread which+uses the object has called `Release()` or has received a return status of+`napi_closing` in response to a call to `BlockingCall()` or `NonBlockingCall()`.+The queue is emptied before the `Napi::ThreadSafeFunction[Ex]` is destroyed. It+is important that `Release()` be the last API call made in conjunction with a+given `Napi::ThreadSafeFunction[Ex]`, because after the call completes, there is+no guarantee that the `Napi::ThreadSafeFunction[Ex]` is still allocated. For the+same reason it is also important that no more use be made of a thread-safe+function after receiving a return value of `napi_closing` in response to a call+to `BlockingCall()` or `NonBlockingCall()`. Data associated with the+`Napi::ThreadSafeFunction[Ex]` can be freed in its `Finalizer` callback which+was passed to `ThreadSafeFunction[Ex]::New()`.++Once the number of threads making use of a `Napi::ThreadSafeFunction[Ex]`+reaches zero, no further threads can start making use of it by calling+`Acquire()`. In fact, all subsequent API calls associated with it, except+`Release()`, will return an error value of `napi_closing`.++## Implementation Differences++The choice between `Napi::ThreadSafeFunction` and `Napi::ThreadSafeFunctionEx`+depends largely on how you plan to execute your native C++ code (the "callback")+on the Node thread.++### [`Napi::ThreadSafeFunction`](threadsafe_function.md)++This API is designed without N-API 5 native support for [optional JavaScript+  function callback feature](https://github.com/nodejs/node/commit/53297e66cb).+  `::New` methods that do not have a `Function` parameter will construct a+  _new_, no-op `Function` on the environment to pass to the underlying N-API+  call.++This API has some dynamic functionality, in that:+- The `[Non]BlockingCall()` methods provide a `Napi::Function` parameter as the+  callback to run when processing the data item on the main thread -- the+  `CallJs` callback. Since the callback is a parameter, it can be changed for+  every call.+- Different C++ data types may be passed with each call of `[Non]BlockingCall()`+  to match the specific data type as specified in the `CallJs` callback.++However, this functionality comes with some **additional overhead** and+situational **memory leaks**:+- The API acts as a "middle-man" between the underlying+  `napi_threadsafe_function`, and dynamically constructs a wrapper for your+  callback on the heap for every call to `[Non]BlockingCall()`.+- In acting in this "middle-man" fashion, the API will call the underlying "make+  call" N-API method on this packaged item. If the API has determined the+  thread-safe function is no longer accessible (eg. all threads have released yet+  there are still items on the queue), **the callback passed to+  [Non]BlockingCall will not execute**. This means it is impossible to perform+  clean-up for calls that never execute their `CallJs` callback. **This may lead+  to memory leaks** if you are dynamically allocating memory.+- The `CallJs` does not receive the thread-safe function's context as a+  parameter. In order for the callback to access the context, it must have a+  reference to either (1) the context directly, or (2) the thread-safe function+  to call `GetContext()`. Furthermore, the `GetContext()` method is not+  _type-safe_, as the method returns an object that can be "any-casted", instead+  of having a static type.++### [`Napi::ThreadSafeFunctionEx`](threadsafe_function_ex.md)++The `ThreadSafeFunctionEx` class is a new implementation to address the+drawbacks listed above. The API is designed with N-API 5's support of an+optional function callback. The API will correctly allow developers to pass+`std::nullptr` instead of a `const Function&` for the callback function+specified in `::New`. It also provides helper APIs to _target_ N-API 4 and+construct a no-op `Function` **or** to target N-API 5 and "construct" an+`std::nullptr` callback. This allows a single codebase to use the same APIs,+with just a switch of the `NAPI_VERSION` compile-time constant.++The removal of the dynamic call functionality has the additional side effects:+- The API does _not_ act as a "middle-man" compared to the non-`Ex`. Once Node
- The API does _not_ act as a "broker" compared to the non-`Ex`. Once Node.js
KevinEady

comment created time in 6 days

Pull request review commentnodejs/node-addon-api

tsfn: implement ThreadSafeFunctionEx

+# Thread-safe Functions++JavaScript functions can normally only be called from a native addon's main+thread. If an addon creates additional threads, then node-addon-api functions+that require a `Napi::Env`, `Napi::Value`, or `Napi::Reference` must not be+called from those threads.++When an addon has additional threads and JavaScript functions need to be invoked+based on the processing completed by those threads, those threads must+communicate with the addon's main thread so that the main thread can invoke the+JavaScript function on their behalf. The thread-safe function APIs provide an+easy way to do this. These APIs provide two types --+[`Napi::ThreadSafeFunction`](threadsafe_function.md) and+[`Napi::ThreadSafeFunctionEx`](threadsafe_function_ex.md) -- as well as APIs to+create, destroy, and call objects of this type. The differences between the two+are subtle and are [highlighted below](#implementation-differences). Regardless+of which type you choose, the API between the two are similar.++`Napi::ThreadSafeFunction[Ex]::New()` creates a persistent reference that holds+a JavaScript function which can be called from multiple threads. The calls+happen asynchronously. This means that values with which the JavaScript callback+is to be called will be placed in a queue, and, for each value in the queue, a+call will eventually be made to the JavaScript function.++`Napi::ThreadSafeFunction[Ex]` objects are destroyed when every thread which+uses the object has called `Release()` or has received a return status of+`napi_closing` in response to a call to `BlockingCall()` or `NonBlockingCall()`.+The queue is emptied before the `Napi::ThreadSafeFunction[Ex]` is destroyed. It+is important that `Release()` be the last API call made in conjunction with a+given `Napi::ThreadSafeFunction[Ex]`, because after the call completes, there is+no guarantee that the `Napi::ThreadSafeFunction[Ex]` is still allocated. For the+same reason it is also important that no more use be made of a thread-safe+function after receiving a return value of `napi_closing` in response to a call+to `BlockingCall()` or `NonBlockingCall()`. Data associated with the+`Napi::ThreadSafeFunction[Ex]` can be freed in its `Finalizer` callback which+was passed to `ThreadSafeFunction[Ex]::New()`.++Once the number of threads making use of a `Napi::ThreadSafeFunction[Ex]`+reaches zero, no further threads can start making use of it by calling+`Acquire()`. In fact, all subsequent API calls associated with it, except+`Release()`, will return an error value of `napi_closing`.++## Implementation Differences++The choice between `Napi::ThreadSafeFunction` and `Napi::ThreadSafeFunctionEx`+depends largely on how you plan to execute your native C++ code (the "callback")+on the Node thread.++### [`Napi::ThreadSafeFunction`](threadsafe_function.md)++This API is designed without N-API 5 native support for [optional JavaScript+  function callback feature](https://github.com/nodejs/node/commit/53297e66cb).+  `::New` methods that do not have a `Function` parameter will construct a+  _new_, no-op `Function` on the environment to pass to the underlying N-API+  call.++This API has some dynamic functionality, in that:+- The `[Non]BlockingCall()` methods provide a `Napi::Function` parameter as the+  callback to run when processing the data item on the main thread -- the+  `CallJs` callback. Since the callback is a parameter, it can be changed for+  every call.+- Different C++ data types may be passed with each call of `[Non]BlockingCall()`+  to match the specific data type as specified in the `CallJs` callback.++However, this functionality comes with some **additional overhead** and+situational **memory leaks**:+- The API acts as a "middle-man" between the underlying+  `napi_threadsafe_function`, and dynamically constructs a wrapper for your+  callback on the heap for every call to `[Non]BlockingCall()`.+- In acting in this "middle-man" fashion, the API will call the underlying "make
- In acting in this "broker" fashion, the API will call the underlying "make
KevinEady

comment created time in 6 days

Pull request review commentnodejs/node-addon-api

tsfn: implement ThreadSafeFunctionEx

+# Thread-safe Functions++JavaScript functions can normally only be called from a native addon's main+thread. If an addon creates additional threads, then node-addon-api functions+that require a `Napi::Env`, `Napi::Value`, or `Napi::Reference` must not be+called from those threads.++When an addon has additional threads and JavaScript functions need to be invoked+based on the processing completed by those threads, those threads must+communicate with the addon's main thread so that the main thread can invoke the+JavaScript function on their behalf. The thread-safe function APIs provide an+easy way to do this. These APIs provide two types --+[`Napi::ThreadSafeFunction`](threadsafe_function.md) and+[`Napi::ThreadSafeFunctionEx`](threadsafe_function_ex.md) -- as well as APIs to+create, destroy, and call objects of this type. The differences between the two+are subtle and are [highlighted below](#implementation-differences). Regardless+of which type you choose, the API between the two are similar.++`Napi::ThreadSafeFunction[Ex]::New()` creates a persistent reference that holds+a JavaScript function which can be called from multiple threads. The calls+happen asynchronously. This means that values with which the JavaScript callback+is to be called will be placed in a queue, and, for each value in the queue, a+call will eventually be made to the JavaScript function.++`Napi::ThreadSafeFunction[Ex]` objects are destroyed when every thread which+uses the object has called `Release()` or has received a return status of+`napi_closing` in response to a call to `BlockingCall()` or `NonBlockingCall()`.+The queue is emptied before the `Napi::ThreadSafeFunction[Ex]` is destroyed. It+is important that `Release()` be the last API call made in conjunction with a+given `Napi::ThreadSafeFunction[Ex]`, because after the call completes, there is+no guarantee that the `Napi::ThreadSafeFunction[Ex]` is still allocated. For the+same reason it is also important that no more use be made of a thread-safe+function after receiving a return value of `napi_closing` in response to a call+to `BlockingCall()` or `NonBlockingCall()`. Data associated with the+`Napi::ThreadSafeFunction[Ex]` can be freed in its `Finalizer` callback which+was passed to `ThreadSafeFunction[Ex]::New()`.++Once the number of threads making use of a `Napi::ThreadSafeFunction[Ex]`+reaches zero, no further threads can start making use of it by calling+`Acquire()`. In fact, all subsequent API calls associated with it, except+`Release()`, will return an error value of `napi_closing`.++## Implementation Differences++The choice between `Napi::ThreadSafeFunction` and `Napi::ThreadSafeFunctionEx`+depends largely on how you plan to execute your native C++ code (the "callback")+on the Node thread.++### [`Napi::ThreadSafeFunction`](threadsafe_function.md)++This API is designed without N-API 5 native support for [optional JavaScript+  function callback feature](https://github.com/nodejs/node/commit/53297e66cb).+  `::New` methods that do not have a `Function` parameter will construct a+  _new_, no-op `Function` on the environment to pass to the underlying N-API+  call.++This API has some dynamic functionality, in that:+- The `[Non]BlockingCall()` methods provide a `Napi::Function` parameter as the+  callback to run when processing the data item on the main thread -- the+  `CallJs` callback. Since the callback is a parameter, it can be changed for+  every call.+- Different C++ data types may be passed with each call of `[Non]BlockingCall()`+  to match the specific data type as specified in the `CallJs` callback.++However, this functionality comes with some **additional overhead** and+situational **memory leaks**:+- The API acts as a "middle-man" between the underlying+  `napi_threadsafe_function`, and dynamically constructs a wrapper for your+  callback on the heap for every call to `[Non]BlockingCall()`.+- In acting in this "middle-man" fashion, the API will call the underlying "make+  call" N-API method on this packaged item. If the API has determined the+  thread-safe function is no longer accessible (eg. all threads have released yet+  there are still items on the queue), **the callback passed to+  [Non]BlockingCall will not execute**. This means it is impossible to perform+  clean-up for calls that never execute their `CallJs` callback. **This may lead+  to memory leaks** if you are dynamically allocating memory.+- The `CallJs` does not receive the thread-safe function's context as a+  parameter. In order for the callback to access the context, it must have a+  reference to either (1) the context directly, or (2) the thread-safe function+  to call `GetContext()`. Furthermore, the `GetContext()` method is not+  _type-safe_, as the method returns an object that can be "any-casted", instead+  of having a static type.++### [`Napi::ThreadSafeFunctionEx`](threadsafe_function_ex.md)++The `ThreadSafeFunctionEx` class is a new implementation to address the+drawbacks listed above. The API is designed with N-API 5's support of an+optional function callback. The API will correctly allow developers to pass+`std::nullptr` instead of a `const Function&` for the callback function+specified in `::New`. It also provides helper APIs to _target_ N-API 4 and+construct a no-op `Function` **or** to target N-API 5 and "construct" an+`std::nullptr` callback. This allows a single codebase to use the same APIs,+with just a switch of the `NAPI_VERSION` compile-time constant.++The removal of the dynamic call functionality has the additional side effects:
The removal of the dynamic call functionality has the following implications:
KevinEady

comment created time in 6 days

Pull request review commentnodejs/node-addon-api

tsfn: implement ThreadSafeFunctionEx

+# Thread-safe Functions++JavaScript functions can normally only be called from a native addon's main+thread. If an addon creates additional threads, then node-addon-api functions+that require a `Napi::Env`, `Napi::Value`, or `Napi::Reference` must not be+called from those threads.++When an addon has additional threads and JavaScript functions need to be invoked+based on the processing completed by those threads, those threads must+communicate with the addon's main thread so that the main thread can invoke the+JavaScript function on their behalf. The thread-safe function APIs provide an+easy way to do this. These APIs provide two types --+[`Napi::ThreadSafeFunction`](threadsafe_function.md) and+[`Napi::ThreadSafeFunctionEx`](threadsafe_function_ex.md) -- as well as APIs to+create, destroy, and call objects of this type. The differences between the two+are subtle and are [highlighted below](#implementation-differences). Regardless+of which type you choose, the API between the two are similar.++`Napi::ThreadSafeFunction[Ex]::New()` creates a persistent reference that holds+a JavaScript function which can be called from multiple threads. The calls+happen asynchronously. This means that values with which the JavaScript callback+is to be called will be placed in a queue, and, for each value in the queue, a+call will eventually be made to the JavaScript function.++`Napi::ThreadSafeFunction[Ex]` objects are destroyed when every thread which+uses the object has called `Release()` or has received a return status of+`napi_closing` in response to a call to `BlockingCall()` or `NonBlockingCall()`.+The queue is emptied before the `Napi::ThreadSafeFunction[Ex]` is destroyed. It+is important that `Release()` be the last API call made in conjunction with a+given `Napi::ThreadSafeFunction[Ex]`, because after the call completes, there is+no guarantee that the `Napi::ThreadSafeFunction[Ex]` is still allocated. For the+same reason it is also important that no more use be made of a thread-safe+function after receiving a return value of `napi_closing` in response to a call+to `BlockingCall()` or `NonBlockingCall()`. Data associated with the+`Napi::ThreadSafeFunction[Ex]` can be freed in its `Finalizer` callback which+was passed to `ThreadSafeFunction[Ex]::New()`.++Once the number of threads making use of a `Napi::ThreadSafeFunction[Ex]`+reaches zero, no further threads can start making use of it by calling+`Acquire()`. In fact, all subsequent API calls associated with it, except+`Release()`, will return an error value of `napi_closing`.++## Implementation Differences++The choice between `Napi::ThreadSafeFunction` and `Napi::ThreadSafeFunctionEx`+depends largely on how you plan to execute your native C++ code (the "callback")+on the Node thread.++### [`Napi::ThreadSafeFunction`](threadsafe_function.md)++This API is designed without N-API 5 native support for [optional JavaScript+  function callback feature](https://github.com/nodejs/node/commit/53297e66cb).+  `::New` methods that do not have a `Function` parameter will construct a+  _new_, no-op `Function` on the environment to pass to the underlying N-API+  call.++This API has some dynamic functionality, in that:+- The `[Non]BlockingCall()` methods provide a `Napi::Function` parameter as the+  callback to run when processing the data item on the main thread -- the+  `CallJs` callback. Since the callback is a parameter, it can be changed for+  every call.+- Different C++ data types may be passed with each call of `[Non]BlockingCall()`+  to match the specific data type as specified in the `CallJs` callback.++However, this functionality comes with some **additional overhead** and+situational **memory leaks**:+- The API acts as a "middle-man" between the underlying+  `napi_threadsafe_function`, and dynamically constructs a wrapper for your+  callback on the heap for every call to `[Non]BlockingCall()`.+- In acting in this "middle-man" fashion, the API will call the underlying "make+  call" N-API method on this packaged item. If the API has determined the+  thread-safe function is no longer accessible (eg. all threads have released yet+  there are still items on the queue), **the callback passed to+  [Non]BlockingCall will not execute**. This means it is impossible to perform+  clean-up for calls that never execute their `CallJs` callback. **This may lead+  to memory leaks** if you are dynamically allocating memory.+- The `CallJs` does not receive the thread-safe function's context as a+  parameter. In order for the callback to access the context, it must have a+  reference to either (1) the context directly, or (2) the thread-safe function+  to call `GetContext()`. Furthermore, the `GetContext()` method is not+  _type-safe_, as the method returns an object that can be "any-casted", instead+  of having a static type.++### [`Napi::ThreadSafeFunctionEx`](threadsafe_function_ex.md)++The `ThreadSafeFunctionEx` class is a new implementation to address the+drawbacks listed above. The API is designed with N-API 5's support of an+optional function callback. The API will correctly allow developers to pass+`std::nullptr` instead of a `const Function&` for the callback function+specified in `::New`. It also provides helper APIs to _target_ N-API 4 and+construct a no-op `Function` **or** to target N-API 5 and "construct" an
construct a no-op `Function` **or** to target N-API 5 and "construct" a
KevinEady

comment created time in 6 days

Pull request review commentnodejs/node-addon-api

tsfn: implement ThreadSafeFunctionEx

+# Thread-safe Functions++JavaScript functions can normally only be called from a native addon's main+thread. If an addon creates additional threads, then node-addon-api functions+that require a `Napi::Env`, `Napi::Value`, or `Napi::Reference` must not be+called from those threads.++When an addon has additional threads and JavaScript functions need to be invoked+based on the processing completed by those threads, those threads must+communicate with the addon's main thread so that the main thread can invoke the+JavaScript function on their behalf. The thread-safe function APIs provide an+easy way to do this. These APIs provide two types --+[`Napi::ThreadSafeFunction`](threadsafe_function.md) and+[`Napi::ThreadSafeFunctionEx`](threadsafe_function_ex.md) -- as well as APIs to+create, destroy, and call objects of this type. The differences between the two+are subtle and are [highlighted below](#implementation-differences). Regardless+of which type you choose, the API between the two are similar.++`Napi::ThreadSafeFunction[Ex]::New()` creates a persistent reference that holds+a JavaScript function which can be called from multiple threads. The calls+happen asynchronously. This means that values with which the JavaScript callback+is to be called will be placed in a queue, and, for each value in the queue, a+call will eventually be made to the JavaScript function.++`Napi::ThreadSafeFunction[Ex]` objects are destroyed when every thread which+uses the object has called `Release()` or has received a return status of+`napi_closing` in response to a call to `BlockingCall()` or `NonBlockingCall()`.+The queue is emptied before the `Napi::ThreadSafeFunction[Ex]` is destroyed. It+is important that `Release()` be the last API call made in conjunction with a+given `Napi::ThreadSafeFunction[Ex]`, because after the call completes, there is+no guarantee that the `Napi::ThreadSafeFunction[Ex]` is still allocated. For the+same reason it is also important that no more use be made of a thread-safe+function after receiving a return value of `napi_closing` in response to a call+to `BlockingCall()` or `NonBlockingCall()`. Data associated with the+`Napi::ThreadSafeFunction[Ex]` can be freed in its `Finalizer` callback which+was passed to `ThreadSafeFunction[Ex]::New()`.++Once the number of threads making use of a `Napi::ThreadSafeFunction[Ex]`+reaches zero, no further threads can start making use of it by calling+`Acquire()`. In fact, all subsequent API calls associated with it, except+`Release()`, will return an error value of `napi_closing`.++## Implementation Differences++The choice between `Napi::ThreadSafeFunction` and `Napi::ThreadSafeFunctionEx`+depends largely on how you plan to execute your native C++ code (the "callback")+on the Node thread.++### [`Napi::ThreadSafeFunction`](threadsafe_function.md)++This API is designed without N-API 5 native support for [optional JavaScript+  function callback feature](https://github.com/nodejs/node/commit/53297e66cb).+  `::New` methods that do not have a `Function` parameter will construct a+  _new_, no-op `Function` on the environment to pass to the underlying N-API+  call.++This API has some dynamic functionality, in that:+- The `[Non]BlockingCall()` methods provide a `Napi::Function` parameter as the+  callback to run when processing the data item on the main thread -- the+  `CallJs` callback. Since the callback is a parameter, it can be changed for+  every call.+- Different C++ data types may be passed with each call of `[Non]BlockingCall()`+  to match the specific data type as specified in the `CallJs` callback.++However, this functionality comes with some **additional overhead** and
Note that this functionality comes with some **additional overhead** and
KevinEady

comment created time in 6 days

Pull request review commentnodejs/node-addon-api

tsfn: implement ThreadSafeFunctionEx

+# Thread-safe Functions++JavaScript functions can normally only be called from a native addon's main+thread. If an addon creates additional threads, then node-addon-api functions+that require a `Napi::Env`, `Napi::Value`, or `Napi::Reference` must not be+called from those threads.++When an addon has additional threads and JavaScript functions need to be invoked+based on the processing completed by those threads, those threads must+communicate with the addon's main thread so that the main thread can invoke the+JavaScript function on their behalf. The thread-safe function APIs provide an+easy way to do this. These APIs provide two types --+[`Napi::ThreadSafeFunction`](threadsafe_function.md) and+[`Napi::ThreadSafeFunctionEx`](threadsafe_function_ex.md) -- as well as APIs to+create, destroy, and call objects of this type. The differences between the two+are subtle and are [highlighted below](#implementation-differences). Regardless+of which type you choose, the API between the two are similar.++`Napi::ThreadSafeFunction[Ex]::New()` creates a persistent reference that holds+a JavaScript function which can be called from multiple threads. The calls+happen asynchronously. This means that values with which the JavaScript callback+is to be called will be placed in a queue, and, for each value in the queue, a+call will eventually be made to the JavaScript function.++`Napi::ThreadSafeFunction[Ex]` objects are destroyed when every thread which+uses the object has called `Release()` or has received a return status of+`napi_closing` in response to a call to `BlockingCall()` or `NonBlockingCall()`.+The queue is emptied before the `Napi::ThreadSafeFunction[Ex]` is destroyed. It+is important that `Release()` be the last API call made in conjunction with a+given `Napi::ThreadSafeFunction[Ex]`, because after the call completes, there is+no guarantee that the `Napi::ThreadSafeFunction[Ex]` is still allocated. For the+same reason it is also important that no more use be made of a thread-safe+function after receiving a return value of `napi_closing` in response to a call+to `BlockingCall()` or `NonBlockingCall()`. Data associated with the+`Napi::ThreadSafeFunction[Ex]` can be freed in its `Finalizer` callback which+was passed to `ThreadSafeFunction[Ex]::New()`.++Once the number of threads making use of a `Napi::ThreadSafeFunction[Ex]`+reaches zero, no further threads can start making use of it by calling+`Acquire()`. In fact, all subsequent API calls associated with it, except+`Release()`, will return an error value of `napi_closing`.++## Implementation Differences++The choice between `Napi::ThreadSafeFunction` and `Napi::ThreadSafeFunctionEx`+depends largely on how you plan to execute your native C++ code (the "callback")+on the Node thread.++### [`Napi::ThreadSafeFunction`](threadsafe_function.md)++This API is designed without N-API 5 native support for [optional JavaScript+  function callback feature](https://github.com/nodejs/node/commit/53297e66cb).+  `::New` methods that do not have a `Function` parameter will construct a+  _new_, no-op `Function` on the environment to pass to the underlying N-API+  call.++This API has some dynamic functionality, in that:+- The `[Non]BlockingCall()` methods provide a `Napi::Function` parameter as the+  callback to run when processing the data item on the main thread -- the+  `CallJs` callback. Since the callback is a parameter, it can be changed for+  every call.+- Different C++ data types may be passed with each call of `[Non]BlockingCall()`+  to match the specific data type as specified in the `CallJs` callback.++However, this functionality comes with some **additional overhead** and+situational **memory leaks**:+- The API acts as a "middle-man" between the underlying
- The API acts as a "broker" between the underlying

more gender-neutral, perhaps?

KevinEady

comment created time in 6 days

Pull request review commentnodejs/node-addon-api

tsfn: implement ThreadSafeFunctionEx

+# Thread-safe Functions++JavaScript functions can normally only be called from a native addon's main+thread. If an addon creates additional threads, then node-addon-api functions+that require a `Napi::Env`, `Napi::Value`, or `Napi::Reference` must not be+called from those threads.++When an addon has additional threads and JavaScript functions need to be invoked+based on the processing completed by those threads, those threads must+communicate with the addon's main thread so that the main thread can invoke the+JavaScript function on their behalf. The thread-safe function APIs provide an+easy way to do this. These APIs provide two types --+[`Napi::ThreadSafeFunction`](threadsafe_function.md) and+[`Napi::ThreadSafeFunctionEx`](threadsafe_function_ex.md) -- as well as APIs to+create, destroy, and call objects of this type. The differences between the two+are subtle and are [highlighted below](#implementation-differences). Regardless+of which type you choose, the API between the two are similar.++`Napi::ThreadSafeFunction[Ex]::New()` creates a persistent reference that holds+a JavaScript function which can be called from multiple threads. The calls+happen asynchronously. This means that values with which the JavaScript callback+is to be called will be placed in a queue, and, for each value in the queue, a+call will eventually be made to the JavaScript function.++`Napi::ThreadSafeFunction[Ex]` objects are destroyed when every thread which+uses the object has called `Release()` or has received a return status of+`napi_closing` in response to a call to `BlockingCall()` or `NonBlockingCall()`.+The queue is emptied before the `Napi::ThreadSafeFunction[Ex]` is destroyed. It+is important that `Release()` be the last API call made in conjunction with a+given `Napi::ThreadSafeFunction[Ex]`, because after the call completes, there is+no guarantee that the `Napi::ThreadSafeFunction[Ex]` is still allocated. For the+same reason it is also important that no more use be made of a thread-safe+function after receiving a return value of `napi_closing` in response to a call+to `BlockingCall()` or `NonBlockingCall()`. Data associated with the+`Napi::ThreadSafeFunction[Ex]` can be freed in its `Finalizer` callback which+was passed to `ThreadSafeFunction[Ex]::New()`.++Once the number of threads making use of a `Napi::ThreadSafeFunction[Ex]`+reaches zero, no further threads can start making use of it by calling+`Acquire()`. In fact, all subsequent API calls associated with it, except+`Release()`, will return an error value of `napi_closing`.++## Implementation Differences++The choice between `Napi::ThreadSafeFunction` and `Napi::ThreadSafeFunctionEx`+depends largely on how you plan to execute your native C++ code (the "callback")+on the Node thread.++### [`Napi::ThreadSafeFunction`](threadsafe_function.md)++This API is designed without N-API 5 native support for [optional JavaScript
This API is designed without N-API 5 native support for [the optional JavaScript
KevinEady

comment created time in 6 days

Pull request review commentnodejs/node-addon-api

tsfn: implement ThreadSafeFunctionEx

+# Thread-safe Functions++JavaScript functions can normally only be called from a native addon's main+thread. If an addon creates additional threads, then node-addon-api functions+that require a `Napi::Env`, `Napi::Value`, or `Napi::Reference` must not be+called from those threads.++When an addon has additional threads and JavaScript functions need to be invoked+based on the processing completed by those threads, those threads must+communicate with the addon's main thread so that the main thread can invoke the+JavaScript function on their behalf. The thread-safe function APIs provide an+easy way to do this. These APIs provide two types --+[`Napi::ThreadSafeFunction`](threadsafe_function.md) and+[`Napi::ThreadSafeFunctionEx`](threadsafe_function_ex.md) -- as well as APIs to+create, destroy, and call objects of this type. The differences between the two+are subtle and are [highlighted below](#implementation-differences). Regardless+of which type you choose, the API between the two are similar.++`Napi::ThreadSafeFunction[Ex]::New()` creates a persistent reference that holds+a JavaScript function which can be called from multiple threads. The calls+happen asynchronously. This means that values with which the JavaScript callback+is to be called will be placed in a queue, and, for each value in the queue, a+call will eventually be made to the JavaScript function.++`Napi::ThreadSafeFunction[Ex]` objects are destroyed when every thread which+uses the object has called `Release()` or has received a return status of+`napi_closing` in response to a call to `BlockingCall()` or `NonBlockingCall()`.+The queue is emptied before the `Napi::ThreadSafeFunction[Ex]` is destroyed. It+is important that `Release()` be the last API call made in conjunction with a+given `Napi::ThreadSafeFunction[Ex]`, because after the call completes, there is+no guarantee that the `Napi::ThreadSafeFunction[Ex]` is still allocated. For the+same reason it is also important that no more use be made of a thread-safe+function after receiving a return value of `napi_closing` in response to a call+to `BlockingCall()` or `NonBlockingCall()`. Data associated with the+`Napi::ThreadSafeFunction[Ex]` can be freed in its `Finalizer` callback which+was passed to `ThreadSafeFunction[Ex]::New()`.++Once the number of threads making use of a `Napi::ThreadSafeFunction[Ex]`+reaches zero, no further threads can start making use of it by calling+`Acquire()`. In fact, all subsequent API calls associated with it, except+`Release()`, will return an error value of `napi_closing`.++## Implementation Differences++The choice between `Napi::ThreadSafeFunction` and `Napi::ThreadSafeFunctionEx`+depends largely on how you plan to execute your native C++ code (the "callback")+on the Node thread.
on the Node.js thread.
KevinEady

comment created time in 6 days

Pull request review commentnodejs/node-addon-api

tsfn: implement ThreadSafeFunctionEx

+# Thread-safe Functions++JavaScript functions can normally only be called from a native addon's main+thread. If an addon creates additional threads, then node-addon-api functions+that require a `Napi::Env`, `Napi::Value`, or `Napi::Reference` must not be+called from those threads.++When an addon has additional threads and JavaScript functions need to be invoked+based on the processing completed by those threads, those threads must+communicate with the addon's main thread so that the main thread can invoke the+JavaScript function on their behalf. The thread-safe function APIs provide an+easy way to do this. These APIs provide two types --+[`Napi::ThreadSafeFunction`](threadsafe_function.md) and+[`Napi::ThreadSafeFunctionEx`](threadsafe_function_ex.md) -- as well as APIs to+create, destroy, and call objects of this type. The differences between the two+are subtle and are [highlighted below](#implementation-differences). Regardless+of which type you choose, the API between the two are similar.
of which type you choose, the APIs between the two are similar.
KevinEady

comment created time in 6 days

push eventgabrielschulhof/node

Gerhard Stoebich

commit sha cb142d13413c1c2c6eadb00a0257059a5fec9533

async_hooks: execute destroy hooks earlier Use a microtask to call destroy hooks in case there are a lot queued as immediate may be scheduled late in case of long running promise chains. Queuing a mircrotasks in GC context is not allowed therefore an interrupt is triggered to do this in JS context as fast as possible. fixes: https://github.com/nodejs/node/issues/34328 refs: https://github.com/nodejs/node/issues/33896 PR-URL: https://github.com/nodejs/node/pull/34342 Fixes: https://github.com/nodejs/node/issues/34328 Refs: https://github.com/nodejs/node/issues/33896 Reviewed-By: Gus Caplan <me@gus.host> Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: James M Snell <jasnell@gmail.com>

view details

Rich Trott

commit sha a9c5b873ca47555aeaaaffa9c7374358f33cc28e

test: move buffer-as-path symlink test to its own test file The buffer-as-path test for fs.symlinkSync() is a bit unusual and potentially error-prone embedded in the general fs.symlink() test. Move it to its own test file. Refs: https://github.com/nodejs/node/pull/34540/files#r463168354 PR-URL: https://github.com/nodejs/node/pull/34569 Reviewed-By: Pranshu Srivastava <rexagod@gmail.com> Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Gerhard Stöbich <deb2001-github@yahoo.de>

view details

Anna Henningsen

commit sha 2ba93e1db4992e73af42c47b445a54c2a767bd6e

async_hooks: fix resource stack for deep stacks 460c81dc0e0 introduced a bug where the execution resource was not stored properly if we needed to call into C++ to extend the stack size. Fix that bug by always storing the resource. Refs: https://github.com/nodejs/node/pull/34319 Fixes: https://github.com/nodejs/node/issues/34556 PR-URL: https://github.com/nodejs/node/pull/34573 Reviewed-By: Andrey Pechkurov <apechkurov@gmail.com> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com> Reviewed-By: Gerhard Stöbich <deb2001-github@yahoo.de> Reviewed-By: Gus Caplan <me@gus.host>

view details

Andrey Pechkurov

commit sha b7a23295e84479843c4975bd6ed876392a9d7602

async_hooks: fix id assignment in fast-path promise hook Native side of fast-path promise hook was not calling JS fastPromiseHook function when there were no async ids previously assigned to the promise. Because of that already created promises could not get id assigned in situations when an async hook without a before listener function is enabled after their creation. As the result executionAsyncId could return wrong id when called within promise's .then(). Refs: https://github.com/nodejs/node/pull/34512 PR-URL: https://github.com/nodejs/node/pull/34548 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com> Reviewed-By: Gerhard Stöbich <deb2001-github@yahoo.de>

view details

Tim Perry

commit sha e5dacc2f8595164e3f25170e65143082c6ae9fc7

doc: document the connection event for HTTP2 & TLS servers PR-URL: https://github.com/nodejs/node/pull/34531 Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: Luigi Pinca <luigipinca@gmail.com>

view details

James M Snell

commit sha 4b0275ab87f3cf60eb990300a5bc2cc05d5f38d5

quic: refactor clientHello Refactor the `'clientHello'` event into a `clientHelloHandler` configuration option and async function. Remove the addContext API as it's not needed. PR-URL: https://github.com/nodejs/node/pull/34541 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Jiawen Geng <technicalcute@gmail.com>

view details

James M Snell

commit sha d96083bad56e97ddef525c2c0db6963d70fd6f6c

quic: introduce QuicCallbackScope Alternative to `CallbackScope` that handles destroying the `QuicSession` in the try_catch cleanup. PR-URL: https://github.com/nodejs/node/pull/34541 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Jiawen Geng <technicalcute@gmail.com>

view details

James M Snell

commit sha 6e65f26b73c67869a3ac5ee2caf0dfd011177d66

quic: use QuicCallbackScope consistently for QuicSession PR-URL: https://github.com/nodejs/node/pull/34541 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Jiawen Geng <technicalcute@gmail.com>

view details

cjihrig

commit sha ee0b44fd93fa695e902a725cbe3da2f18c032c55

tools: add meta.fixable to fixable lint rules This commit adds the meta.fixable property to all fixable ESLint rules. This is required as of ESLint 7.6.0. PR-URL: https://github.com/nodejs/node/pull/34589 Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com> Reviewed-By: Luigi Pinca <luigipinca@gmail.com>

view details

cjihrig

commit sha a6a368498425c846e4074c24a97bb93d760f1db2

tools: update ESLint to 7.6.0 Update ESLint to 7.6.0 PR-URL: https://github.com/nodejs/node/pull/34589 Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com> Reviewed-By: Luigi Pinca <luigipinca@gmail.com>

view details

Robert Nagy

commit sha 8d8090b9bb3ee657e20f0cb00fdc1c120a58537c

test: fix flaky http-parser-timeout-reset Refs: https://github.com/nodejs/node/pull/34578#issuecomment-667941698 PR-URL: https://github.com/nodejs/node/pull/34609 Reviewed-By: Richard Lau <riclau@uk.ibm.com> Reviewed-By: Myles Borins <myles.borins@gmail.com>

view details

Myles Borins

commit sha 54746bb763ebea0dc7e99d88ff4b379bcd680964

module: unflag Top-Level Await This unflags Top-Level await so it can be used by default in the module goal. This is accomplished by manually setting the --harmony-top-level-await flag. We are allowing this as a one of approval based on circumstances. It is not a precedent that future harmony features will be manually enabled. Refs: https://github.com/nodejs/node/issues/34551 PR-URL: https://github.com/nodejs/node/pull/34558 Reviewed-By: Mary Marchini <oss@mmarchini.me> Reviewed-By: Zeyu Yang <himself65@outlook.com> Reviewed-By: Gus Caplan <me@gus.host> Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com> Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com> Reviewed-By: Shelley Vohr <codebytere@gmail.com>

view details

Bradley Farias

commit sha ca26eae9665b846831be2289714d8c21897b0d44

repl: give repl entries unique names This is a workaround for the REPL for a problem when multiple of the entries have the same source text Fixes: https://github.com/nodejs/node/issues/1337 Refs: https://bugs.chromium.org/p/v8/issues/detail?id=10284 PR-URL: https://github.com/nodejs/node/pull/34372 Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de> Reviewed-By: Anto Aravinth <anto.aravinth.cse@gmail.com>

view details

James M Snell

commit sha 744a284ccc943d352fd2cc15e35aaf720b1139ae

stream: support async for stream impl functions PR-URL: https://github.com/nodejs/node/pull/34416 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: Anto Aravinth <anto.aravinth.cse@gmail.com>

view details

James M Snell

commit sha 74df7496ff6d899e4b8ceed9505a641e79ad6366

async_hooks: add AsyncResource.bind utility Creates an internal AsyncResource and binds a function to it, ensuring that the function is invoked within execution context in which bind was called. PR-URL: https://github.com/nodejs/node/pull/34574 Reviewed-By: Stephen Belanger <admin@stephenbelanger.com> Reviewed-By: Gus Caplan <me@gus.host> Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: Andrey Pechkurov <apechkurov@gmail.com> Reviewed-By: Gerhard Stöbich <deb2001-github@yahoo.de>

view details

Anna Henningsen

commit sha 0bb70b0a02c2e6d5e6de61f9f9619f379b09a92e

test: replace flaky pummel regression tests These tests were written a long time ago, and use the allocation of large amounts of unused memory as a way to detect use-after-free problems with Buffers. As a result, the tests are resource-intensive and may crash because of that. Replace them with a more modern test. We don’t explicitly try to *detect* use-after-free conditions, and instead rely on e.g. ASAN (or the process just crashing hard) to do that for us. Fixes: https://github.com/nodejs/node/issues/34527 PR-URL: https://github.com/nodejs/node/pull/34530 Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: Andrey Pechkurov <apechkurov@gmail.com> Reviewed-By: Jiawen Geng <technicalcute@gmail.com>

view details

Gerhard Stoebich

commit sha 3ea94ec84510f5ecd08b75e6e10ef7c5f5df4fe8

async_hooks: improve property descriptors in als.bind The length property should be non enumerable to match behavior of normal functions. The asyncResource property is enumerable and therefore it should be also writable to avoid issues like there: https://github.com/nodejs/node/pull/30932#discussion_r379679982 Both properties should be configurable. Refs: https://github.com/nodejs/node/pull/34574 PR-URL: https://github.com/nodejs/node/pull/34620 Reviewed-By: Andrey Pechkurov <apechkurov@gmail.com> Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: James M Snell <jasnell@gmail.com>

view details

Rich Trott

commit sha 319c275b26db7ccfaac4ef67f9dedefc2379d0dd

doc: use _can_ to describe actions in quic.md Per Microsoft style guide: > When ability is what you need to express, it's OK to use _can_ to > describe actions or tasks that the reader or program is able to do. > Use _might_ to express possibility. Don't use _may_, which might be > interpreted as providing permission. Refs: https://docs.microsoft.com/en-us/style-guide/a-z-word-list-term-collections/c/can-may Refs: https://github.com/nodejs/node/pull/34353#issuecomment-659169228 PR-URL: https://github.com/nodejs/node/pull/34613 Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Gerhard Stöbich <deb2001-github@yahoo.de>

view details

Rich Trott

commit sha d5c7aec3cb7c90d026cfa9bfb2c75ed2ad3ee15f

doc: use _can_ to describe actions in quic.md Per Microsoft style guide: > When ability is what you need to express, it's OK to use _can_ to > describe actions or tasks that the reader or program is able to do. > Use _might_ to express possibility. Don't use _may_, which might be > interpreted as providing permission. Refs: https://docs.microsoft.com/en-us/style-guide/a-z-word-list-term-collections/c/can-may Refs: https://github.com/nodejs/node/pull/34353#issuecomment-659169228 PR-URL: https://github.com/nodejs/node/pull/34613 Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Gerhard Stöbich <deb2001-github@yahoo.de>

view details

Corey Butler

commit sha 84b35b286769758610173291c6e9fd9eebdaaf1f

doc: clarify process.title inconsistencies Many users assume the act of assigning a value to `process.title` will update the name of their application in apps like macOS Activity Monitor or Windows Services Manager. This has worked in the past, but fails in some versions of Node.js. Ultimately developers are left confused, especially when it works in one version of Node.js and not another. Given the recurring nature and complexity of the underlying problem, it does not seem like a resolvable problem. This note clarifies the source of the problem, sets developer expectations. Refs: https://github.com/nodejs/node/issues/28945 PR-URL: https://github.com/nodejs/node/pull/34557 Fixes: https://github.com/nodejs/node/issues/34280 Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: Rich Trott <rtrott@gmail.com>

view details

push time in 6 days

delete branch gabrielschulhof/node

delete branch : n-api-make-tests-C

delete time in 6 days

PR closed nodejs/node

Reviewers
test: convert most N-API tests from C++ to C n-api test
  • Prefix functions with static to make them local
  • Remove anonymous namespaces
  • nullptr -> NULL
  • .cc -> .c and update binding.gyp
  • static_cast<x>() -> (x)()
  • Replace new/delete with malloc()/free() (only in test_callback_scope)
  • Move lambda out and convert to local function (only in test_callback_scope)
  • Remove superfluous #include <vector> (only in test_callback_scope_recurse)

Some tests are best left as C++.

ls -l test/{node-api,js-native-api}/*/*.cc

for the rest.

<!-- Thank you for your pull request. Please provide a description above and review the requirements below.

Bug fixes and new features should include tests and possibly benchmarks.

Contributors guide: https://github.com/nodejs/node/blob/master/CONTRIBUTING.md -->

Checklist

<!-- Remove items that do not apply. For completed items, change [ ] to [x]. -->

  • [x] make -j4 test (UNIX), or vcbuild test (Windows) passes
  • [x] tests and/or benchmarks are included
  • [x] commit message follows commit guidelines

<!-- Developer's Certificate of Origin 1.1

By making a contribution to this project, I certify that:

(a) The contribution was created in whole or in part by me and I have the right to submit it under the open source license indicated in the file; or

(b) The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate open source license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same open source license (unless I am permitted to submit under a different license), as indicated in the file; or

(c) The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it.

(d) I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the open source license(s) involved. -->

+67 -77

3 comments

8 changed files

gabrielschulhof

pr closed time in 6 days

pull request commentnodejs/node

test: convert most N-API tests from C++ to C

Landed in 734327280daeb0f358a89651b119283631bf7211.

gabrielschulhof

comment created time in 6 days

push eventnodejs/node

Gabriel Schulhof

commit sha 734327280daeb0f358a89651b119283631bf7211

test: convert most N-API tests from C++ to C * Prefix functions with `static` to make them local * Remove anonymous namespaces * `nullptr` -> `NULL` * .cc -> .c and update binding.gyp * `static_cast<x>()` -> `(x)()` * Replace `new`/`delete` with `malloc()`/`free()` (only in test_callback_scope) * Move lambda out and convert to local function (only in test_callback_scope) * Remove superfluous `#include <vector>` (only in test_callback_scope_recurse) Some tests are best left as C++. ```bash ls -l test/{node-api,js-native-api}/*/*.cc ``` for those remaining as C++ tests. Signed-off-by: Gabriel Schulhof <gabriel.schulhof@intel.com> PR-URL: https://github.com/nodejs/node/pull/34615 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Jiawen Geng <technicalcute@gmail.com> Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com> Reviewed-By: Gerhard Stöbich <deb2001-github@yahoo.de>

view details

push time in 6 days

pull request commentnodejs/node-addon-api

WIP: add safer unwrap

We should call the function SafeUnwrap not SaferUnwrap and the C preprocessor variable should be NAPI_SAFE_UNWRAP. If present, it should do the safe napi_unwrap, otherwise it should do the regular napi_unwrap. The way it is now is kind of confusing to me.

@DaAitch is this related to https://github.com/nodejs/node-addon-api/pull/732 (multiple inheritance)?

@mhdawson maybe we should have a second target in the test/binding.gyp file which only gets run in the CI and is considered failed if it successfully compile. Might be kind of a crude check though, because it might be quite an effort to start analyzing the compiler's stderr output to see if it generated the right error message. Our many supported platforms each have a compiler that produces its own individual message, and the message may change with the version of the compiler, so if we analyzed compiler stderr output we might be signing up for quite a maintenance burden.

The PR needs a rebase.

DaAitch

comment created time in 7 days

push eventgabrielschulhof/node-addon-examples

Gabriel Schulhof

commit sha 16112d380978811a372eeb54e7c357e687c45266

remove wrapper_ from napi_wrap examples Signed-off-by: Gabriel Schulhof <gabriel.schulhof@intel.com> Fixes: https://github.com/nodejs/node-addon-examples/issues/140

view details

Gabriel Schulhof

commit sha 24bf26d30be37dc9b1ce087ac2cfa4c0a35df3e9

fix up 6_object_wrap

view details

Gabriel Schulhof

commit sha 5c94d85edef80e4a9edca8cf953bae9b3ff6bcec

fix 7_factory_wrap and 8_passing_wrapped as well

view details

push time in 7 days

delete branch gabrielschulhof/node-addon-examples

delete branch : gh-pages

delete time in 7 days

push eventgabrielschulhof/node-addon-examples

Gabriel Schulhof

commit sha 7d2794e4afa7b50371ea25257f9e694c39cf8fea

fix up 6_object_wrap

view details

Gabriel Schulhof

commit sha 904b9b2b9fbc3fe1476f0741c045570696d05bfd

fix 7_factory_wrap and 8_passing_wrapped as well

view details

push time in 7 days

PR opened nodejs/node-addon-examples

remove wrapper_ from napi_wrap examples

The variable is only ever assigned and then cleaned up, never used.

+6 -21

0 comment

6 changed files

pr created time in 7 days

create barnchgabrielschulhof/node-addon-examples

branch : remove-wrapper_

created branch time in 7 days

push eventgabrielschulhof/node-addon-examples

Gabriel Schulhof

commit sha 47b0215f871256565b86d67816e4199acf7a2459

make N-API examples context-sensitive (#141)

view details

Jim Schlight

commit sha 3ccbb6af86868c3fe317bdf623630777001b962c

Remove unneeded Napi::HandleScope objects (#144) * Remove unneeded Napi::HandleScope objects

view details

Jim Schlight

commit sha 4d4dcedce52263e043fd351b206fbfd23be3df57

Tutorial website (#146) * Website is operational without search * Remove website directory from testing * Formating tweaks * Tooling to support publishing to GitHub Pages * Initial site implementation complete * Remove unneeded TypeScript files * Restore original author's LICENSE file

view details

Jim Schlight

commit sha adb6ab37c4a8ec7de24746545544246fd2cbbbf5

Add GitHub Action to rebuild and publish website (#149)

view details

push time in 7 days

push eventgabrielschulhof/node

Gabriel Schulhof

commit sha bc27d2f2f1dd4ac24da40c3dbcb534a9c5c04445

fixup! make variables static too

view details

push time in 8 days

push eventgabrielschulhof/node

Gabriel Schulhof

commit sha 5ac87368cd16dc04ed90c9fa572091a310a14704

test: convert most N-API tests from C++ to C * Prefix functions with `static` to make them local * Remove anonymous namespaces * `nullptr` -> `NULL` * .cc -> .c and update binding.gyp * `static_cast<x>()` -> `(x)()` * Replace `new`/`delete` with `malloc()`/`free()` (only in test_callback_scope) * Move lambda out and convert to local function (only in test_callback_scope) * Remove superfluous `#include <vector>` (only in test_callback_scope_recurse) Some tests are best left as C++. ```bash ls -l test/{node-api,js-native-api}/*/*.cc ``` for the rest. Signed-off-by: Gabriel Schulhof <gabriel.schulhof@intel.com>

view details

push time in 8 days

PR opened nodejs/node

Reviewers
test: convert most N-API tests from C++ to C
  • Prefix functions with static to make them local
  • Remove anonymous namespaces
  • nullptr -> NULL
  • .cc -> .c and update binding.gyp
  • static_cast<x>() -> (x)()
  • Replace new/delete with malloc()/free() (only in test_callback_scope)
  • Move lambda out and convert to local function (only in test_callback_scope)
  • Remove superfluous #include <vector> (only in test_callback_scope_recurse)

Some tests are best left as C++.

ls -l test/{node-api,js-native-api}/*/*.cc

for the rest.

<!-- Thank you for your pull request. Please provide a description above and review the requirements below.

Bug fixes and new features should include tests and possibly benchmarks.

Contributors guide: https://github.com/nodejs/node/blob/master/CONTRIBUTING.md -->

Checklist

<!-- Remove items that do not apply. For completed items, change [ ] to [x]. -->

  • [x] make -j4 test (UNIX), or vcbuild test (Windows) passes
  • [x] tests and/or benchmarks are included
  • [x] commit message follows commit guidelines

<!-- Developer's Certificate of Origin 1.1

By making a contribution to this project, I certify that:

(a) The contribution was created in whole or in part by me and I have the right to submit it under the open source license indicated in the file; or

(b) The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate open source license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same open source license (unless I am permitted to submit under a different license), as indicated in the file; or

(c) The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it.

(d) I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the open source license(s) involved. -->

+63 -60

0 comment

8 changed files

pr created time in 8 days

push eventgabrielschulhof/node

Gabriel Schulhof

commit sha 63f1343ce5b9943fbccfe51186fd5221d6451a5c

test: convert most N-API tests from C++ to C * Prefix functions with `static` to make them local * Remove anonymous namespaces * `nullptr` -> `NULL` * .cc -> .c and update binding.gyp * `static_cast<x>()` -> `(x)()` * Replace `new`/`delete` with `malloc()`/`free()` (only in test_callback_scope) * Move lambda out and convert to local function (only in test_callback_scope) * Remove superfluous `#include <vector>` (only in test_callback_scope_recurse) Some tests are best left as C++. ```bash ls -l test/{node-api,js-native-api}/*/*.cc ``` for the rest. Signed-off-by: Gabriel Schulhof <gabriel.schulhof@intel.com>

view details

push time in 8 days

push eventgabrielschulhof/node

Gabriel Schulhof

commit sha 69c004f5af1d3f4a53d1f9029717a75367ef4e33

test: convert most N-API tests from C++ to C * Prefix functions with `static` to make them local * Remove anonymous namespaces * `nullptr` -> `NULL` * .cc -> .c and update binding.gyp * `static_cast<x>()` -> `(x)()` * Replace `new`/`delete` with `malloc()`/`free()` (only in test_callback_scope) * Move lambda out and convert to local function (only in test_callback_scope) * Remove superfluous `#include <vector>` (only in test_callback_scope_recurse) Some tests are best left as C++. ```bash ls -l test/{node-api,js-native-api}/*/*.cc ``` for the rest.

view details

push time in 8 days

create barnchgabrielschulhof/node

branch : n-api-make-tests-C

created branch time in 8 days

push eventgabrielschulhof/node

Michael Dawson

commit sha 15333ad552b3e81cc325f31c9920ea7bbb07be0c

doc: clarify N-API version 1 Refs: https://github.com/nodejs/node-addon-api/issues/760 Clarify which version of 8.x in which N-API version 1 matches the shape in later versions like 10.x Signed-off-by: Michael Dawson <michael_dawson@ca.ibm.com> PR-URL: https://github.com/nodejs/node/pull/34344 Reviewed-By: Gus Caplan <me@gus.host> Reviewed-By: Gabriel Schulhof <gabriel.schulhof@intel.com>

view details

Guy Bedford

commit sha 1fe39f0b4bad8da38e5f02542c176d5999ad3ecb

module: disable cjs snapshotting into esm loader PR-URL: https://github.com/nodejs/node/pull/34467 Reviewed-By: Bradley Farias <bradley.meck@gmail.com> Reviewed-By: Geoffrey Booth <webmaster@geoffreybooth.com>

view details

Gireesh Punathil

commit sha 4692e284e305e3ec2418f7f5005bed8d3e62ad11

lib: absorb `path` error cases Absorb low level libuv failure in the process initialization phase Fixes: https://github.com/nodejs/node/issues/33759 Refs: https://github.com/nodejs/node/issues/33759#issuecomment-663980558 PR-URL: https://github.com/nodejs/node/pull/34519 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: Zeyu Yang <himself65@outlook.com> Reviewed-By: Harshitha K P <harshitha014@gmail.com>

view details

Andrey Pechkurov

commit sha 019ea073babe6db0cf19ffc68e908de5252a1bc8

async_hooks: don't reuse resource in HttpAgent when queued PR-URL: https://github.com/nodejs/node/pull/34439 Fixes: https://github.com/nodejs/node/issues/34401 Refs: https://github.com/nodejs/node/pull/27581 Reviewed-By: Vladimir de Turckheim <vlad2t@hotmail.com> Reviewed-By: Gerhard Stöbich <deb2001-github@yahoo.de>

view details

himself65

commit sha 2c4f30deea107bf42df4de1d3e7373d52d0d35f5

fs: fix when path is buffer on fs.symlinkSync PR-URL: https://github.com/nodejs/node/pull/34540 Fixes: https://github.com/nodejs/node/issues/34514 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Anto Aravinth <anto.aravinth.cse@gmail.com> Reviewed-By: Pranshu Srivastava <rexagod@gmail.com>

view details

Rich Trott

commit sha 2d2a812645db794698abec602a10366e41305b98

test: remove unneeded flag check in test-vm-memleak The `common` module checks that necessary flags are being used, so a check in the test itself is no longer necessary. PR-URL: https://github.com/nodejs/node/pull/34528 Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de> Reviewed-By: Luigi Pinca <luigipinca@gmail.com>

view details

Gus Caplan

commit sha dc00a07426f0b2dee9bfe39c766a703eb9b5b880

Revert "module: disable cjs snapshotting into esm loader" This reverts commit 1fe39f0b4bad8da38e5f02542c176d5999ad3ecb. PR-URL: https://github.com/nodejs/node/pull/34562 Reviewed-By: Bradley Farias <bradley.meck@gmail.com> Reviewed-By: Guy Bedford <guybedford@gmail.com>

view details

Andrey Pechkurov

commit sha 1e470510ff74391d7d4ec382909ea8960d2d2fbc

src: fix unused namespace member in node_util PR-URL: https://github.com/nodejs/node/pull/34565 Reviewed-By: Zeyu Yang <himself65@outlook.com> Reviewed-By: Richard Lau <riclau@uk.ibm.com> Reviewed-By: James M Snell <jasnell@gmail.com>

view details

James M Snell

commit sha a97b5f9c6acd101ec20d9278a840b2cb6ef94ac9

quic: use OpenSSL built-in cert and hostname validation PR-URL: https://github.com/nodejs/node/pull/34533 Reviewed-By: Anna Henningsen <anna@addaleax.net>

view details

Gabriel Schulhof

commit sha 0cc2a54a53831968d5c955cb6cc09a2c46bd75ea

n-api: simplify bigint-from-word creation Macro `CHECK_MAYBE_EMPTY_WITH_PREAMBLE()` does the work of checking the `TryCatch` and returning `napi_pending_exception` so this change reuses it for `napi_create_bigint_words()`. Signed-off-by: Gabriel Schulhof <gabriel.schulhof@intel.com> PR-URL: https://github.com/nodejs/node/pull/34554 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>

view details

Mary Marchini

commit sha 6cab3b0e261dfaedd42ca46ee04957d4ec6d1be0

build: auto start Jenkins CI via PR labels Add an Action that will find every PR with the `request-ci` label and will start a Jenkins CI for each of these Pull Requests. The scheduler event is used to circumvent GitHub Actions limitations on Pull Requests from forks (where secrets are not accessible and the GITHUB_TOKEN is read-only). If the Action fails to start a CI, it will add a `request-ci-failed` label and will leave a comment with the error message from NCU. Fixes: https://github.com/nodejs/github-bot/issues/234 PR-URL: https://github.com/nodejs/node/pull/34089 Reviewed-By: Christian Clauss <cclauss@me.com>

view details

Mary Marchini

commit sha c8c2f4d0ae6162ab29ab7eabe87a409c7f836a66

doc: update .mailmap for mmarchini PR-URL: https://github.com/nodejs/node/pull/34586 Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: James M Snell <jasnell@gmail.com>

view details

Mary Marchini

commit sha f5df3c25826ad8b9d9e18b3ef449f8d40593a418

doc: update mmarchini contact info PR-URL: https://github.com/nodejs/node/pull/34586 Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: James M Snell <jasnell@gmail.com>

view details

Mary Marchini

commit sha 8b3ad75b03ee49688ac0e9e4aa2481231fd4ff96

doc: add mmarchini pronouns PR-URL: https://github.com/nodejs/node/pull/34586 Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: James M Snell <jasnell@gmail.com>

view details

Gabriel Schulhof

commit sha cc7ec889e863433c248bc4b5c8e33f61ccc40f29

n-api: support type-tagging objects `napi_instanceof()` is insufficient for reliably establishing the data type to which a pointer stored with `napi_wrap()` or `napi_create_external()` inside a JavaScript object points. Thus, we need a way to "mark" an object with a value that, when later retrieved, can unambiguously tell us whether it is safe to cast the pointer stored inside it to a certain structure. Such a check must survive loading/unloading/multiple instances of an addon, so we use UUIDs chosen *a priori*. Fixes: https://github.com/nodejs/node/issues/28164 Co-authored-by: Anna Henningsen <github@addaleax.net> PR-URL: https://github.com/nodejs/node/pull/28237 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Signed-off-by: Gabriel Schulhof <gabriel.schulhof@intel.com>

view details

Rich Trott

commit sha 3e9caaf5051961f640664a138297de11bb5c5c26

doc: use consistent capitalization for addons Sometimes _addon_ is capitalized and sometimes not. Capitalizing it seems peculiar and hard to justify. Standardize on treating it like other common nouns. PR-URL: https://github.com/nodejs/node/pull/34536 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com> Reviewed-By: Daijiro Wachi <daijiro.wachi@gmail.com>

view details

Rich Trott

commit sha 3b9a252dccb0ca296f18379ae8a5716d892a2cca

doc: simplify and clarify console.assert() documentation PR-URL: https://github.com/nodejs/node/pull/34544 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com> Reviewed-By: Luigi Pinca <luigipinca@gmail.com>

view details

Rich Trott

commit sha 770a02d3c826e81d52b10af9a7143ad33fe31487

doc: use consistent spelling for "falsy" We use "falsy" in multiple places in our docs, but only use "false-y" in one place in url.md. Replace it with "falsy". PR-URL: https://github.com/nodejs/node/pull/34545 Reviewed-By: Anto Aravinth <anto.aravinth.cse@gmail.com> Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: Pranshu Srivastava <rexagod@gmail.com> Reviewed-By: Ron Korving <ron@ronkorving.nl> Reviewed-By: Yuta Hiroto <hello@hiroppy.me> Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com>

view details

Robert Nagy

commit sha 849d9e7b90ebaae930a28a7994b3a56ec4f280c6

http: provide keep-alive timeout response header In http 1.1 persistent connection protocol there is a timing race where the client sends the request and then the server kills the connection (due to inactivity) before receiving the client's request. By providing a keep-alive header it is possible to provide the client a hint of when idle timeout would occur and avoid the race. Fixes: https://github.com/nodejs/node/issues/34560 PR-URL: https://github.com/nodejs/node/pull/34561 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: Zeyu Yang <himself65@outlook.com> Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com> Reviewed-By: Pranshu Srivastava <rexagod@gmail.com>

view details

Mary Marchini

commit sha 4268c6112feaf82d7ca171c381b269ebfcf403f7

build: fix auto-start-ci script path PR-URL: https://github.com/nodejs/node/pull/34588 Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: Richard Lau <riclau@uk.ibm.com>

view details

push time in 8 days

push eventgabrielschulhof/node

Rich Trott

commit sha a6f75dfa6497d8e2d4ef16ebd360fa48d4a73282

doc: add lint disabling comment for collaborator list Disable linting for prohibited strings in the collaborator list so that sam-github does not have to be sam-GitHub. Refs: https://github.com/nodejs/remark-preset-lint-node/pull/96 Signed-off-by: Rich Trott <rtrott@gmail.com> PR-URL: https://github.com/nodejs/node/pull/33719 Reviewed-By: Richard Lau <riclau@uk.ibm.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Beth Griggs <Bethany.Griggs@uk.ibm.com>

view details

Nick Schonning

commit sha 067578a9c36710a875d446a06fb4576f729fdfbd

doc: remove shell dollar signs without output Related to https://github.com/nodejs/remark-preset-lint-node/pull/94 PR-URL: https://github.com/nodejs/node/pull/33692 Reviewed-By: Michaël Zasso <targos@protonmail.com> Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: Rich Trott <rtrott@gmail.com>

view details

Daniel Bevenius

commit sha d0a7b9f048ebcff76c09ca0f63a5bb190c9731c2

src: remove unnecessary ToLocalChecked call PR-URL: https://github.com/nodejs/node/pull/33683 Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: David Carlier <devnexen@gmail.com> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com> Reviewed-By: Juan José Arboleda <soyjuanarbol@gmail.com>

view details

Daniel Bevenius

commit sha 63147ba3e7689b4c2359fa088f063cdf01c6604c

src: use ToLocal in SafeGetenv This commit replaces the IsEmpty call to use ToLocal instead which allows for the following ToLocalChecked function call to be avoided. PR-URL: https://github.com/nodejs/node/pull/33695 Reviewed-By: Richard Lau <riclau@uk.ibm.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: David Carlier <devnexen@gmail.com>

view details

Sagar Jadhav

commit sha 8a516707b04baa20cf0766eafe2765d07396305a

test: changed function to arrow function Convert callback functions that are anonymous to arrow functions for better readability. PR-URL: https://github.com/nodejs/node/pull/33711 Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Juan José Arboleda <soyjuanarbol@gmail.com> Reviewed-By: Zeyu Yang <himself65@outlook.com>

view details

Rich Trott

commit sha 8d44c00cba7dbddfdda3a921833be36d324eccea

tools: update remark-preset-lint-node from 1.15.0 to 1.15.1 PR-URL: https://github.com/nodejs/node/pull/33727 Reviewed-By: Michaël Zasso <targos@protonmail.com> Reviewed-By: Richard Lau <riclau@uk.ibm.com>

view details

Rich Trott

commit sha c3f50e3241b513a12085f8e3066e425245ac3d01

doc: remove default parameter value from header In the docs, we specify the default value of function parameters in the list below the header. There is one exception where we use default parameter notation. Change that instance to be like the rest of the docs instead. I rather like the default parameter notation, and I get why we didn't use it to begin with. (The notation didn't exist in JavaScript at the time.) I wouldn't mind switching to it, but that would result in big churn. That can be a separate topic of discussion. For now, though, let's get the docs consistent. PR-URL: https://github.com/nodejs/node/pull/33752 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com>

view details

Derek Lewis

commit sha 31063f9f859fa5820d925740824cf4234d49ad11

doc: normalize C++ code block info strings Prior to this commit, C++ fenced code blocks in Markdown files had inconsistent info strings. This has been corrected to standarize on the one with the highest frequency in the doc/api/ dir. Stats: > 'cpp' => 19, > 'C++' => 6, > 'c++' => 3, PR-URL: https://github.com/nodejs/node/pull/33483 Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: David Carlier <devnexen@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>

view details

Anna Henningsen

commit sha 99d34ea61c05d951afc328a4757467620caba9cd

benchmark: fix async-resource benchmark In the benchmark, because it performs asynchronous operations before writing its HTTP replies, the underlying socket can be closed by the peer before the response is written. Since 28e6626ce7020, that means that attempting to `.end()` the HTTP response results in an uncaught exception, breaking the benchmark. Fix that by checking whether the response object has been destroyed or not before attempting to call `.end()`. https://github.com/nodejs/node/issues/33591 PR-URL: https://github.com/nodejs/node/pull/33642 Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com> Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Juan José Arboleda <soyjuanarbol@gmail.com>

view details

antsmartian

commit sha 1a5ef19b366096158b1a2da742e8bb08112d1e8f

stream: fix the spellings PR-URL: https://github.com/nodejs/node/pull/33635 Reviewed-By: Zeyu Yang <himself65@outlook.com> Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: Robert Nagy <ronagy@icloud.com> Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de> Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com>

view details

Rich Trott

commit sha fec56a9a8433361dda22b59dbc4bee93f849cc0c

doc: change "pre Node.js v0.10" to "prior to Node.js 0.10" The phrasing "pre Node.js v0.10" is not grammatical, as "pre" is not a word. This also changes "Node.js v0.10" to "Node.js 0.10". We dropped use of the "v" prefix in prose some time ago to avoid confusion as to whether "v8" referred to the V8 JavaScript engine or Node.js 8.x. PR-URL: https://github.com/nodejs/node/pull/33754 Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: Richard Lau <riclau@uk.ibm.com> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com> Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com>

view details

Rich Trott

commit sha 215325d4e722bca81f5aa058f0d310f81a8ddb93

doc: remove "currently" from util.md PR-URL: https://github.com/nodejs/node/pull/33756 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com> Reviewed-By: Michaël Zasso <targos@protonmail.com> Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com>

view details

Rich Trott

commit sha 55d84a8efebfd6735f59cfa2818343d1783695c1

doc: remove "currently" from addons.md PR-URL: https://github.com/nodejs/node/pull/33756 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com> Reviewed-By: Michaël Zasso <targos@protonmail.com> Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com>

view details

Rich Trott

commit sha 772d407650922f36a376bbb0e1897c9230361bc8

doc: remove "currently" from vm.md PR-URL: https://github.com/nodejs/node/pull/33756 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com> Reviewed-By: Michaël Zasso <targos@protonmail.com> Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com>

view details

Rich Trott

commit sha 43f32e3c761d00cc3ab622735cf2f1575d01aaa3

doc: remove "currently" from repl.md PR-URL: https://github.com/nodejs/node/pull/33756 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com> Reviewed-By: Michaël Zasso <targos@protonmail.com> Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com>

view details

Rich Trott

commit sha 2db875c3bc71be54279d50f265f986beab19fe91

doc: add formatting for version numbers to doc-style-guide.md PR-URL: https://github.com/nodejs/node/pull/33755 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Richard Lau <riclau@uk.ibm.com> Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com>

view details

Pranshu Srivastava

commit sha 6db21cce308a6b67962668c7afc1af53c5c4ff77

doc: fix linting in doc-style-guide.md Disable lint checks (enable prohibited-strings remark-lint) for doc-style-guide.md:66. This was producing lint errors in builds on master. PR-URL: https://github.com/nodejs/node/pull/33787 Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: Daniel Bevenius <daniel.bevenius@gmail.com>

view details

João Reis

commit sha 7aac9832f2451ce7bc204539a49ee8fd5ab2bcbc

fs: close file descriptor of promisified truncate Original PR: PR-URL: https://github.com/nodejs/node/pull/28858 Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> PR-URL: https://github.com/nodejs/node/pull/34239 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Richard Lau <riclau@uk.ibm.com> Reviewed-By: Gerhard Stöbich <deb2001-github@yahoo.de>

view details

Daniel Bevenius

commit sha 8d258c43c3265c2fc5617c740d86ea940e12f722

src: use Check() instead of FromJust in environment This commit replaces FromJust() calls with Check() in places where the value that FromJust() returns is not used. PR-URL: https://github.com/nodejs/node/pull/33706 Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: David Carlier <devnexen@gmail.com>

view details

Daniel Bevenius

commit sha 68615a01d1b95a2cc705f16acdab3cd7cb9f023e

build: add LINT_CPP_FILES to checkimports check This commit adds the prerequisites which contains all the files to lint. Currently the only the files in 'src' will be checked. PR-URL: https://github.com/nodejs/node/pull/33697 Reviewed-By: Richard Lau <riclau@uk.ibm.com> Reviewed-By: Michaël Zasso <targos@protonmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>

view details

push time in 8 days

push eventgabrielschulhof/node

AshCripps

commit sha d0bfbd6ebdd72fcbb1471d79d6fd0f5017bff7f6

test: mark test-dgram-multicast-ssmv6-multi-process flaky refs: https://github.com/nodejs/node/issues/32946 Mark this test as flaky on linux Ive used sequential.status as a template for this file PR-URL: https://github.com/nodejs/node/pull/33498 Refs: https://github.com/nodejs/node/issues/32946 Reviewed-By: Richard Lau <riclau@uk.ibm.com> Reviewed-By: Luigi Pinca <luigipinca@gmail.com>

view details

Guy Bedford

commit sha f98e927523b746ca61b2fef06944d47ecbf23b17

doc: correct CommonJS self-resolve spec PR-URL: https://github.com/nodejs/node/pull/33391 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Geoffrey Booth <webmaster@geoffreybooth.com>

view details

Ruben Bridgewater

commit sha 36f3ccda1f4b0aeec7db48172e943ff145246eb9

repl: add builtinModules This adds an alias to `_builtinLibs` that is documented and should as such also be accessed publicly. It does not contain any underscored modules. Signed-off-by: Ruben Bridgewater <ruben@bridgewater.de> PR-URL: https://github.com/nodejs/node/pull/33295 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Michaël Zasso <targos@protonmail.com>

view details

Dan Fabulich

commit sha 53e29e404af17ee6f4e91aa038ab3171b99808cb

cli: support --experimental-top-level-await in NODE_OPTIONS PR-URL: https://github.com/nodejs/node/pull/33495 Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de> Reviewed-By: Michaël Zasso <targos@protonmail.com>

view details

Bartosz Sosnowski

commit sha 837eb2af49c7e00a082a526a365e58290370caeb

fs: unify style in preprocessSymlinkDestination Removes the else after return to match rest of the style of the function. PR-URL: https://github.com/nodejs/node/pull/33496 Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>

view details

Deep310

commit sha 2444ba293a723ffa6e1047c24d8f62a72f653ab3

doc: fixed a grammatical error in path.md It said, " The path.basename() methods returns the last portion....". "Methods" was wrong and it is fixed to "method". PR-URL: https://github.com/nodejs/node/pull/33489 Reviewed-By: Richard Lau <riclau@uk.ibm.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>

view details

Dominykas Blyžė

commit sha 2f249ed63a39d2dd7c9dd839f629aa7b1e3e1e7f

deps: V8: cherry-pick 548f6c81d424 Original commit message: [runtime] Don't track transitions for certainly detached maps Previously such maps were marked as prototype, but that has bad performance / memory characteristics if objects are used as dictionaries. Bug: b:148346655, v8:10339 Change-Id: I287c5664c8b7799a084669aaaffe3affcf73e95f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2179322 Reviewed-by: Igor Sheludko <ishell@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#67537} Refs: https://github.com/v8/v8/commit/548f6c81d4246736a7feafd7995fdf6f24ed1149 PR-URL: https://github.com/nodejs/node/pull/33484 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Matheus Marchini <mat@mmarchini.me> Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>

view details

Derek Lewis

commit sha 70e166ff778d870bcb228a56ab4646483c146ff3

doc: normalize C++ code block info strings Prior to this commit, C++ fenced code blocks in Markdown files had inconsistent info strings. This has been corrected to standarize on the one with the highest frequency in the doc/api/ dir. Stats: > 'cpp' => 19, > 'C++' => 6, > 'c++' => 3, PR-URL: https://github.com/nodejs/node/pull/33483 Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: David Carlier <devnexen@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>

view details

dfabulich

commit sha 94de4acadd3754448c82e22ea828095f3cb02a27

doc: mention --experimental-top-level-await flag PR-URL: https://github.com/nodejs/node/pull/33473 Reviewed-By: Gus Caplan <me@gus.host> Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>

view details

Alhadis

commit sha 1e6b600f364472c53c4da2dbc515156d7905cf28

doc: eliminate dead space in API section's sidebar This commit improves overall usability on desktop by removing the "dead" (non-interactive) regions between links in the API section's navigation. No visible changes have been made; this enhancement is purely tactile in nature. PR-URL: https://github.com/nodejs/node/pull/33469 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>

view details

Anna Henningsen

commit sha f4cfe94d90c59e0e6b3cdbdad333f71c9ef20216

Revert "n-api: detect deadlocks in thread-safe function" This reverts commit d26ca06c16f497ffa5ac4845a27922d5058a9318 because it breaks running the tests in debug mode, as `v8::Isolate::GetCurrent()` is not allowed if no `Isolate` is active on the current thread. Refs: https://github.com/nodejs/node/pull/33276 Refs: https://github.com/nodejs/node/pull/32860 PR-URL: https://github.com/nodejs/node/pull/33453 Reviewed-By: Daniel Bevenius <daniel.bevenius@gmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: David Carlier <devnexen@gmail.com> Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com> Reviewed-By: Gabriel Schulhof <gabriel.schulhof@intel.com>

view details

Ben Noordhuis

commit sha d5688561b37807829bf53efec9b92609c9beb9ce

wasi: relax WebAssembly.Instance type check Instances coming from different VM contexts don't pass `instanceof` type checks because each context has its own copy of the built-in globals. After review of the relevant code it seems like it should be safe to relax the type check and that is what this commit does: `wasi.start()` now accepts any input that walks and quacks like a WebAssembly.Instance or WebAssembly.Memory instance. Fixes: https://github.com/nodejs/node/issues/33415 PR-URL: https://github.com/nodejs/node/pull/33431 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>

view details

Derek Lewis

commit sha 8fc790b54d9e3fc1ddb11a62fb7d819ecdd885e3

doc,tools: properly syntax highlight API ref docs Prior to this commit, all <pre> tags were being highlighted as JavaScript. This has been corrected to syntax highlight all languages appearing in the API reference docs. This was accomplished by using highlight.js instead of SHJS for the frontend lib. * remove SHJS JavaScript code * add highlight.js bundle * fix script tags to reflect replacement * migrate CSS to use highlight.js classes * add appropriate documentation * ensure api_assets README.md stays interal Fixes: https://github.com/nodejs/node/issues/33363 PR-URL: https://github.com/nodejs/node/pull/33442 Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de> Reviewed-By: Ujjwal Sharma <ryzokuken@disroot.org>

view details

rickyes

commit sha b23e4b29217bccdb23fee99620bcbd2b6d778f93

net: refactor check for Windows PR-URL: https://github.com/nodejs/node/pull/33497 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Richard Lau <riclau@uk.ibm.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>

view details

Anna Henningsen

commit sha 5fd500389ebdc1a95363a86dfb5e8c3328439c76

test: fix flaky test-trace-atomics-wait This adds a possible ordering of the trace events that was missing from the list previously. Fixes: https://github.com/nodejs/node/issues/33427 PR-URL: https://github.com/nodejs/node/pull/33428 Reviewed-By: Michaël Zasso <targos@protonmail.com> Reviewed-By: Richard Lau <riclau@uk.ibm.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>

view details

Antoine du HAMEL

commit sha be2ff7e47e77cf6d55264ad2d477758cdc35ffb7

doc: fix typo in pathToFileURL example PR-URL: https://github.com/nodejs/node/pull/33418 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>

view details

Ben Noordhuis

commit sha e0680cc26f026cf2e20b1db97b1a4faa7018a1a4

src: remove BeforeExit callback list It obscures the fact that there is only a single BeforeExit action. Just call that statically from `EmitBeforeExit()`. PR-URL: https://github.com/nodejs/node/pull/33386 Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Richard Lau <riclau@uk.ibm.com> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com> Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: James M Snell <jasnell@gmail.com>

view details

Ben Noordhuis

commit sha 3d7d6d4f1d86893ed36c34a473ac415e114e7cb3

wasi,worker: handle termination exception Be careful when emitting the 'beforeExit' event. It's not allowed to call into the runtime when a termination exception is pending. Fixes: https://github.com/nodejs/node/issues/33377 PR-URL: https://github.com/nodejs/node/pull/33386 Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Richard Lau <riclau@uk.ibm.com> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com> Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: James M Snell <jasnell@gmail.com>

view details

Nikolai Vavilov

commit sha 81a875f5dca11062259ff65f168f066d9cbf7913

doc: fix Buffer.from(object) documentation Only strings are supported for objects supporting `Symbol.toPrimitive`. PR-URL: https://github.com/nodejs/node/pull/33327 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>

view details

Adrian Estrada

commit sha c0534f7b8d43d7c59d7795906cd48725dbba0ea0

benchmark: fixing http_server_for_chunky_client.js PR-URL: https://github.com/nodejs/node/pull/33271 Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>

view details

push time in 8 days

push eventgabrielschulhof/node

Tobias Nießen

commit sha cd9827f1054b0b24d1d015daf8ed2b4e78eb8e4d

napi: fix memory corruption vulnerability Fixes: https://hackerone.com/reports/784186 CVE-ID: CVE-2020-8174 PR-URL: https://github.com/nodejs-private/node-private/pull/203 Reviewed-By: Beth Griggs <Bethany.Griggs@uk.ibm.com> Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com> Reviewed-By: Tobias Nießen <tniessen@tnie.de>

view details

James M Snell

commit sha 33e9a122417d727a6ccc93588334cdd5386633a7

deps: update nghttp2 to 1.41.0 Fixes: https://hackerone.com/reports/446662 CVE-ID: CVE-2020-11080 PR-URL: https://github.com/nodejs-private/node-private/pull/204 Backport-PR-URL: https://github.com/nodejs-private/node-private/pull/207 Reviewed-By: Beth Griggs <Bethany.Griggs@uk.ibm.com> Reviewed-By: Sam Roberts <vieuxtech@gmail.com>

view details

James M Snell

commit sha 881c244a4e1b857d883cd105cd035a1fd6ed3fa6

http2: implement support for max settings entries Adds the maxSettings option to limit the number of settings entries allowed per SETTINGS frame. Default 32 Signed-off-by: James M Snell <jasnell@gmail.com> Fixes: https://hackerone.com/reports/446662 CVE-ID: CVE-2020-11080 PR-URL: https://github.com/nodejs-private/node-private/pull/204 Backport-PR-URL: https://github.com/nodejs-private/node-private/pull/207 Reviewed-By: Beth Griggs <Bethany.Griggs@uk.ibm.com> Reviewed-By: Sam Roberts <vieuxtech@gmail.com>

view details

Richard Lau

commit sha bd78c6ea465375be418f95751188f39f193457b8

deps: backport ICU-20958 to fix CVE-2020-10531 Add floating patch for ICU 64.2 from https://github.com/unicode-org/icu/commit/18b212f235c8b1dea3b8bbd0accd57340b32ba55. Original commit message: ICU-21032 Backport to 64.x: ICU-20958 Prevent SEGV_MAPERR in append See #971 (cherry picked from commit b7d08bc04a4296982fcef8b6b8a354a9e4e7afca) Refs: https://unicode-org.atlassian.net/browse/ICU-20958 Refs: https://github.com/unicode-org/icu/pull/1155 CVE-ID: CVE-2020-10531 PR-URL: https://github.com/nodejs/node/pull/33572 Reviewed-By: Beth Griggs <Bethany.Griggs@uk.ibm.com> Reviewed-By: Steven R Loomis <srloomis@us.ibm.com>

view details

Shigeki Ohtsu

commit sha 0ad797025662077588133c828f7fefdfe3d0887e

deps: fix OPENSSLDIR on Windows Backslashes and spaces are need to be escaped to define OPENSSLDIR to "C:\Program Files\Common Files\SSL". PR-URL: https://github.com/nodejs/node/pull/29456 Refs: https://github.com/nodejs/node/pull/29455 Reviewed-By: Richard Lau <riclau@uk.ibm.com> Reviewed-By: Sam Roberts <vieuxtech@gmail.com> Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Rich Trott <rtrott@gmail.com>

view details

Beth Griggs

commit sha 23adb548a57db0c56e359265108e7fe71d8b4f73

2020-06-02, Version 10.21.0 'Dubnium' (LTS) This is a security release. Vulnerabilities fixed: - CVE-2020-8174: napi_get_value_string_*() allows various kinds of memory corruption (High). - CVE-2020-10531: ICU-20958 Prevent SEGV_MAPERR in append (High). - CVE-2020-11080: HTTP/2 Large Settings Frame DoS (Low). PR-URL: https://github.com/nodejs-private/node-private/pull/211

view details

Beth Griggs

commit sha 0bd44b4a88b742a07898790ed4ee568b14454f07

Working on v10.21.1 PR-URL: https://github.com/nodejs-private/node-private/pull/211

view details

Kamil Rytarowski

commit sha 24b927ab669ce08b7bc6c2c74f42cf78e1804ee8

build: allow clang 10+ in configure.py Detected on NetBSD/amd64. Fixes: https://github.com/nodejs/node/issues/29536 PR-URL: https://github.com/nodejs/node/pull/29541 Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: David Carlier <devnexen@gmail.com> Reviewed-By: Jiawen Geng <technicalcute@gmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Richard Lau <riclau@uk.ibm.com>

view details

Richard Lau

commit sha 145dcc2c1c0cceee2bf402c8288f3dba3f5e5977

build: move doc versions JSON file out of out/doc Move the generated previous doc versions JSON file out of `out/doc` to prevent it being included in the distributed packages. Signed-off-by: Richard Lau <riclau@uk.ibm.com> PR-URL: https://github.com/nodejs/node/pull/32728 Fixes: https://github.com/nodejs/build/issues/2276 Reviewed-By: Shelley Vohr <codebytere@gmail.com> Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: Jiawen Geng <technicalcute@gmail.com>

view details

Sam Roberts

commit sha 543656928c8bd5582e14cf13067893b15a141b63

test: flaky test-stdout-close-catch on freebsd Refs: https://github.com/nodejs/node/issues/28803 PR-URL: https://github.com/nodejs/node/pull/32849 Reviewed-By: Richard Lau <riclau@uk.ibm.com> Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de> Reviewed-By: Juan José Arboleda <soyjuanarbol@gmail.com> Reviewed-By: Anna Henningsen <anna@addaleax.net>

view details

Richard Lau

commit sha 9915774d181914349d8dda4577cb7875e47a1008

build: log detected compilers in --verbose mode Log the versions of the detected compilers when the configure script is run with `--verbose` to help verify which compiler is being used if multiple toolchains are installed on the system. Signed-off-by: Richard Lau <riclau@uk.ibm.com> PR-URL: https://github.com/nodejs/node/pull/32715 Backport-PR-URL: https://github.com/nodejs/node/pull/32820 Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com> Reviewed-By: Rod Vagg <rod@vagg.org> Reviewed-By: Sam Roberts <vieuxtech@gmail.com> Reviewed-By: Anna Henningsen <anna@addaleax.net>

view details

Sam Roberts

commit sha 89a306bca9088a79aed3fb3fd511fff82178d3cb

deps: fix V8 compiler error with clang++-11 Fixes: https://github.com/nodejs/node/issues/33040 error: type 'antlr4::tree::TerminalNode *' cannot be narrowed to 'bool' in initializer list [-Wc++11-narrowing] ParameterList result{{}, {}, context->VARARGS(), {}}; Occurs twice: ../../deps/v8/src/torque/ast-generator.cc:123:32: ../../deps/v8/src/torque/ast-generator.cc:144:32: PR-URL: https://github.com/nodejs/node/pull/33094 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Michaël Zasso <targos@protonmail.com> Reviewed-By: Richard Lau <riclau@uk.ibm.com>

view details

Michaël Zasso

commit sha 3acc89f8f2caa2c59c5c04f4acc340156b22daaf

deps: V8: backport cd21f71f9cb5 Original commit message: [parser] Validate destructuring assignment pattern in correct classifier Previously we'd first accumulate errors to the parent and validate the destructuring pattern in the parent. In the case of ParseArguments this will invalidly propagate binding pattern errors from one argument to the next. The reason why ParseArguments keeps track of binding pattern errors is because it could also be used to parse async arrow function parameters. If we see async(a,b) we don't yet know whether this is the head of an async arrow function, or a call to async with arguments a and b. Bug: v8:8241 Change-Id: I670ab9a9c6f2e0bee399808b02a465ae1afa7c3f Reviewed-on: https://chromium-review.googlesource.com/c/1296229 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#56887} Refs: https://github.com/v8/v8/commit/cd21f71f9cb592b2f9520b97c86eb5456e0e8e6d Fixes: https://github.com/nodejs/node/issues/23142 PR-URL: https://github.com/nodejs/node/pull/33862 Reviewed-By: Richard Lau <riclau@uk.ibm.com>

view details

Ben Noordhuis

commit sha aaf2f827c6f1be1bdb73d1a6293d6b8f45fce4bf

inspector: more conservative minimum stack size PTHREAD_STACK_MIN is 2 KB with musl, which is too small to safely receive signals. PTHREAD_STACK_MIN + MINSIGSTKSZ is 8 KB on arm64, which is the musl architecture with the biggest MINSIGSTKSZ so let's use that as a lower bound and let's quadruple it just in case. Backport-PR-URL: https://github.com/nodejs/node/pull/33720 PR-URL: https://github.com/nodejs/node/pull/27855 Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Eugene Ostroukhov <eostroukhov@google.com> Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Rich Trott <rtrott@gmail.com>

view details

Hassaan Pasha

commit sha ef9413be1ae73427ee7f4cb062326ddbe5121b2f

deps: upgrade openssl sources to 1.1.1f This updates all sources in deps/openssl/openssl by: $ cd deps/openssl/ $ rm -rf openssl $ tar zxf ~/tmp/openssl-1.1.1f.tar.gz $ mv openssl-1.1.0h openssl $ git add --all openssl $ git commit openssl Backport-PR-URL: https://github.com/nodejs/node/pull/32982 PR-URL: https://github.com/nodejs/node/pull/32583 Reviewed-By: Sam Roberts <vieuxtech@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Tobias Nießen <tniessen@tnie.de>

view details

Hassaan Pasha

commit sha 94702c1560a2f8188d8e8478052f669d6f866653

deps: upgrade openssl sources to 1.1.1g This updates all sources in deps/openssl/openssl by: $ cd deps/openssl/ $ rm -rf openssl $ tar zxf ~/tmp/openssl-1.1.1g.tar.gz $ mv openssl-1.1.1g openssl $ git add --all openssl $ git commit openssl PR-URL: https://github.com/nodejs/node/pull/32982 Reviewed-By: Richard Lau <riclau@uk.ibm.com>

view details

Hassaan Pasha

commit sha 745b32926085e05e121c0756189ae1f88efe8827

deps: update archs files for OpenSSL-1.1.1g After an OpenSSL source update, all the config files need to be regenerated and committed by: $ cd deps/openssl/config $ make $ git add deps/openssl/config/archs $ git add deps/openssl/openssl/include/crypto/bn_conf.h $ git add deps/openssl/openssl/include/crypto/dso_conf.h $ git add deps/openssl/openssl/include/openssl/opensslconf.h $ git commit PR-URL: https://github.com/nodejs/node/pull/32982 Reviewed-By: Richard Lau <riclau@uk.ibm.com>

view details

Jason Macgowan

commit sha 74b00cca64e480a74bf1792576db46ef31824f2f

tls: allow empty subject even with altNames defined Behavior described in https://github.com/nodejs/node/issues/11771 is still true even though the issue is closed. This PR is to allow DNS and URI names, even when there is not a subject. Refs: https://github.com/nodejs/node/issues/11771 PR-URL: https://github.com/nodejs/node/pull/22906 Reviewed-By: James M Snell <jasnell@gmail.com>

view details

cjihrig

commit sha 193d1d0e84132a84f509996607c94ef6bfe85a63

doc: document fs.watchFile() bigint option This commit documents the bigint option to fs.watchFile(), which has been supported since v10.5.0. PR-URL: https://github.com/nodejs/node/pull/32128 Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Richard Lau <riclau@uk.ibm.com>

view details

Luigi Pinca

commit sha 3dbd8cd3a9b5786ec3ecb5fac3bec23810324678

Revert "test: mark empty udp tests flaky on OS X" This reverts commit 24a4f76709bd9edc8d86e9f3fb4d5e3c7d4c3d69. PR-URL: https://github.com/nodejs/node/pull/32489 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Beth Griggs <Bethany.Griggs@uk.ibm.com>

view details

push time in 8 days

issue openednodejs/node

Create and document callback function pointer types for env cleanup hooks

We should add function pointer types for the env cleanup hook callbacks, especially with the impending addition of async cleanup hooks.

created time in 9 days

issue closednodejs/node

Introduce status `napi_cannot_call_into_js`

napi_call_function() and other N-APIs that use NAPI_PREAMBLE() return napi_pending_exception when env->can_call_into_js() is no longer true. We should distinguish between a pending exception and an inability to call into JS.

Re: https://github.com/nodejs/node-addon-api/issues/591

closed time in 9 days

gabrielschulhof

issue commentnodejs/node

Introduce status `napi_cannot_call_into_js`

@mhdawson that's actually not a bad idea. The issue will remain tagged even if it is closed, and will not inflate the open issue count unnecessarily.

gabrielschulhof

comment created time in 9 days

issue openednodejs/abi-stable-node

Discussion: N-API 7

Might it be time for a new version of N-API?

We have the buffer detaching stuff marked as experimental in all three LTS releases, so we could just define these APIs as N-API 7.

We also have type-tagging and asynchronous env cleanup coming on master, but those still need to be backported. As v10.x approaches EOL it is increasingly unlikely that they will be backported all the way there. Thus, it might make sense to sync our N-API version bump with the EOL of 10.x.

Shall we formalize and document our policy for moving APIs out of experimental and into a stable version of N-API?

created time in 9 days

issue commentnodejs/node-addon-api

Weird problem with callbacks

@amunhoz do you think you could create a minimal example that reproduces the problem and give us a link to the resulting code?

amunhoz

comment created time in 9 days

issue closednodejs/node-addon-api

napi_throw_error function syntax in Node v8.2.1 and below is different from N-API V1 docs

In Node v8.2.1 N-API docs syntax for napi_throw_error is: NODE_EXTERN napi_status napi_throw_error(napi_env env, const char* msg);

Whereas in the latest Node v14 docs syntax is: NAPI_EXTERN napi_status napi_throw_error(napi_env env, const char* code, const char* msg); Node v14 docs mention that this method was introduced in N-API version 1 in Node v8.0.0.

code argument is missing in the Node v8.2.1.

When I compile my native add-on compiled using NAPI in Node v8.17.0 it fails to work in Node v8.2.1. And due to syntax differences, the module fails to compile on 8.2.1.

closed time in 9 days

kanikashah90

issue commentnodejs/node-addon-api

napi_throw_error function syntax in Node v8.2.1 and below is different from N-API V1 docs

The documentation fix to address this issue has landed in core at https://github.com/nodejs/node/pull/34344.

kanikashah90

comment created time in 9 days

issue closednodejs/node-addon-api

errors from node-addon-api on node 8.0.0

I'm not sure what to do with this. the version matrix (https://nodejs.org/api/n-api.html#n_api_n_api_version_matrix) says that napi v1 is present but experimental in 8.0.0. I guess that's not entirely correct?

In file included from ../packages/dd-trace/src/native/metrics/main.cc:17:
node_modules/node-addon-api/napi.h:1058:24: error: unknown type name 'napi_async_context'
                       napi_async_context context = nullptr) const;
                       ^
node_modules/node-addon-api/napi.h:1061:24: error: unknown type name 'napi_async_context'
                       napi_async_context context = nullptr) const;
                       ^
node_modules/node-addon-api/napi.h:1065:24: error: unknown type name 'napi_async_context'
                       napi_async_context context = nullptr) const;
                       ^
node_modules/node-addon-api/napi.h:1058:43: error: cannot initialize a parameter of type 'int' with an rvalue of type 'nullptr_t'
                       napi_async_context context = nullptr) const;
                                          ^         ~~~~~~~
node_modules/node-addon-api/napi.h:1058:43: note: passing argument to parameter 'context' here
/Users/gus.caplan/go/src/github.com/DataDog/dd-trace-js/node_modules/node-addon-api/napi.h:1061:43: error: cannot initialize a parameter of type 'int' with an rvalue of type 'nullptr_t'
                       napi_async_context context = nullptr) const;
                                          ^         ~~~~~~~
node_modules/node-addon-api/napi.h:1061:43: note: passing argument to parameter 'context' here
node_modules/node-addon-api/napi.h:1065:43: error: cannot initialize a parameter of type 'int' with an rvalue of type 'nullptr_t'
                       napi_async_context context = nullptr) const;
                                          ^         ~~~~~~~
node_modules/node-addon-api/napi.h:1065:43: note: passing argument to parameter 'context' here
node_modules/node-addon-api/napi.h:1087:7: error: unknown type name 'napi_deferred'
      napi_deferred _deferred;
      ^
node_modules/node-addon-api/napi.h:1238:30: error: unknown type name 'napi_async_context'
                             napi_async_context context = nullptr) const;
                             ^
node_modules/node-addon-api/napi.h:1241:30: error: unknown type name 'napi_async_context'
                             napi_async_context context = nullptr) const;
                             ^
node_modules/node-addon-api/napi.h:1245:30: error: unknown type name 'napi_async_context'
                             napi_async_context context = nullptr) const;
                             ^
node_modules/node-addon-api/napi.h:1238:49: error: cannot initialize a parameter of type 'int' with an rvalue of type 'nullptr_t'
                             napi_async_context context = nullptr) const;
                                                ^         ~~~~~~~
node_modules/node-addon-api/napi.h:1238:49: note: passing argument to parameter 'context' here
node_modules/node-addon-api/napi.h:1241:49: error: cannot initialize a parameter of type 'int' with an rvalue of type 'nullptr_t'
                             napi_async_context context = nullptr) const;
                                                ^         ~~~~~~~
node_modules/node-addon-api/napi.h:1241:49: note: passing argument to parameter 'context' here
node_modules/node-addon-api/napi.h:1245:49: error: cannot initialize a parameter of type 'int' with an rvalue of type 'nullptr_t'
                             napi_async_context context = nullptr) const;
                                                ^         ~~~~~~~
node_modules/node-addon-api/napi.h:1245:49: note: passing argument to parameter 'context' here
node_modules/node-addon-api/napi.h:1359:12: error: unknown type name 'NAPI_NO_RETURN'
    static NAPI_NO_RETURN void Fatal(const char* location, const char* message);
           ^
node_modules/node-addon-api/napi.h:1966:14: error: unknown type name 'napi_async_context'
    operator napi_async_context() const;
             ^
node_modules/node-addon-api/napi.h:1972:5: error: unknown type name 'napi_async_context'
    napi_async_context _context;
    ^
node_modules/node-addon-api/napi.h:2420:20: error: unknown type name 'napi_node_version'
      static const napi_node_version* GetNodeVersion(Env env);
                   ^
In file included from ../packages/dd-trace/src/native/metrics/main.cc:17:
In file included from node_modules/node-addon-api/napi.h:2426:
node_modules/node-addon-api/napi-inl.h:320:24: error: use of undeclared identifier 'napi_run_script'
  napi_status status = napi_run_script(_env, script, &result);
                       ^
node_modules/node-addon-api/napi-inl.h:505:24: error: use of undeclared identifier 'napi_is_promise'
  napi_status status = napi_is_promise(_env, _value, &result);
                       ^
fatal error: too many errors emitted, stopping now [-ferror-limit=]

closed time in 9 days

devsnek

issue commentnodejs/node-addon-api

errors from node-addon-api on node 8.0.0

The documentation fix to address this issue has landed in core at https://github.com/nodejs/node/pull/34344.

devsnek

comment created time in 9 days

issue commentnodejs/node-addon-api

Is it possible to determine the type of an NAPI::Object in a non-global context?

In summary, it sounds like proper support for native add-ons to correctly support vm.runInNewContext() needs to be built from the core on up.

jschlight

comment created time in 9 days

issue commentnodejs/node-addon-api

Refactor test/threadsafe_function/threadsafe_function.js with async/await

Marking as "good first issue" because this does not involve changing the native code, but only the JS portion of the test.

gabrielschulhof

comment created time in 9 days

issue commentnodejs/node-addon-api

Entering the V8 API without proper locking in place

At first blush it sounds like you Napi::Function::MakeCallback if you have a Napi::Function available. It's not sufficient to simply use Napi::Function::Call because the stack is not set up for entering V8.

bsrdjan

comment created time in 9 days

PR closed nodejs/node

doc: mention null special-case for `napi_typeof` doc n-api

The documentation said napi_typeof is similar to the typeof operator, but typeof null detects 'object' while napi_typeof(a_null_value) detects napi_null.

Checklist
+6 -1

1 comment

1 changed file

goto-bus-stop

pr closed time in 9 days

pull request commentnodejs/node

doc: mention null special-case for `napi_typeof`

Landed in 64481c2b133f9314c560c635f06da1abfaf3123a.

goto-bus-stop

comment created time in 9 days

push eventnodejs/node

Renée Kooi

commit sha 64481c2b133f9314c560c635f06da1abfaf3123a

doc: mention null special-case for `napi_typeof` The documentation said `napi_typeof` is similar to the `typeof` operator, but the `typeof null` detects `'object'` while `napi_typeof(a_null_value)` detects `napi_null`. PR-URL: https://github.com/nodejs/node/pull/34577 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Gabriel Schulhof <gabriel.schulhof@intel.com> Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: David Carlier <devnexen@gmail.com>

view details

push time in 9 days

Pull request review commentnodejs/node

n-api,src: provide asynchronous cleanup hooks

+#define NAPI_EXPERIMENTAL

The reason is that the code might be used with other N-API implementations which may or may not require C++. For example, https://github.com/jerryscript-project/iotjs/ is pure C and implements some Node.js APIs like async work. It would be encouraging if the tests built against such outside implementations without having to add a C++ compiler to their build system.

AFAICT it's only a couple of static_casts and two lambdas which would have to be moved out of the body of their containing functions.

addaleax

comment created time in 11 days

Pull request review commentnodejs/node

n-api,src: provide asynchronous cleanup hooks

+#define NAPI_EXPERIMENTAL

This should be a C file, not a C++ file.

addaleax

comment created time in 11 days

Pull request review commentnodejs/node

n-api,src: provide asynchronous cleanup hooks

 napi_status napi_remove_env_cleanup_hook(napi_env env,   return napi_ok; } +struct napi_async_cleanup_hook_handle__ {+  node::AsyncCleanupHookHandle handle;+};++napi_status napi_add_async_cleanup_hook(+    napi_env env,+    void (*fun)(void* arg, void(* cb)(void*), void* cbarg),+    void* arg,+    napi_async_cleanup_hook_handle* remove_handle) {+  CHECK_ENV(env);+  CHECK_ARG(env, fun);++  auto handle = node::AddEnvironmentCleanupHook(env->isolate, fun, arg);+  if (remove_handle != nullptr) {+    *remove_handle = new napi_async_cleanup_hook_handle__ { std::move(handle) };+  }++  return napi_ok;+}++napi_status napi_remove_async_cleanup_hook(+    napi_env env,+    napi_async_cleanup_hook_handle remove_handle) {+  CHECK_ENV(env);+  CHECK_ARG(env, remove_handle);++  node::RemoveEnvironmentCleanupHook(std::move(remove_handle->handle));+  delete remove_handle;++  return napi_ok;
  return napi_clear_last_error(env);
addaleax

comment created time in 11 days

Pull request review commentnodejs/node

n-api,src: provide asynchronous cleanup hooks

 napi_status napi_remove_env_cleanup_hook(napi_env env,   return napi_ok; } +struct napi_async_cleanup_hook_handle__ {+  node::AsyncCleanupHookHandle handle;+};++napi_status napi_add_async_cleanup_hook(+    napi_env env,+    void (*fun)(void* arg, void(* cb)(void*), void* cbarg),+    void* arg,+    napi_async_cleanup_hook_handle* remove_handle) {+  CHECK_ENV(env);+  CHECK_ARG(env, fun);++  auto handle = node::AddEnvironmentCleanupHook(env->isolate, fun, arg);+  if (remove_handle != nullptr) {+    *remove_handle = new napi_async_cleanup_hook_handle__ { std::move(handle) };+  }++  return napi_ok;
  return napi_clear_last_error(env);
addaleax

comment created time in 11 days

PR closed nodejs/node

Reviewers
n-api: support type-tagging objects C++ n-api semver-minor

napi_instanceof() is insufficient for reliably establishing the data type to which a pointer stored with napi_wrap() or napi_create_external() inside a JavaScript object points. Thus, we need a way to "mark" an object with a value that, when later retrieved, can unambiguously tell us whether it is safe to cast the pointer stored inside it to a certain structure.

Re: https://github.com/nodejs/node/issues/28164

<!-- Thank you for your pull request. Please provide a description above and review the requirements below.

Bug fixes and new features should include tests and possibly benchmarks.

Contributors guide: https://github.com/nodejs/node/blob/master/CONTRIBUTING.md -->

Checklist

<!-- Remove items that do not apply. For completed items, change [ ] to [x]. -->

  • [x] make -j4 test (UNIX), or vcbuild test (Windows) passes
  • [x] tests and/or benchmarks are included
  • [x] documentation is changed or added
  • [x] commit message follows commit guidelines
+545 -0

43 comments

14 changed files

gabrielschulhof

pr closed time in 11 days

pull request commentnodejs/node

n-api: support type-tagging objects

Landed in cc7ec889e863433c248bc4b5c8e33f61ccc40f29.

gabrielschulhof

comment created time in 11 days

push eventnodejs/node

Gabriel Schulhof

commit sha cc7ec889e863433c248bc4b5c8e33f61ccc40f29

n-api: support type-tagging objects `napi_instanceof()` is insufficient for reliably establishing the data type to which a pointer stored with `napi_wrap()` or `napi_create_external()` inside a JavaScript object points. Thus, we need a way to "mark" an object with a value that, when later retrieved, can unambiguously tell us whether it is safe to cast the pointer stored inside it to a certain structure. Such a check must survive loading/unloading/multiple instances of an addon, so we use UUIDs chosen *a priori*. Fixes: https://github.com/nodejs/node/issues/28164 Co-authored-by: Anna Henningsen <github@addaleax.net> PR-URL: https://github.com/nodejs/node/pull/28237 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Signed-off-by: Gabriel Schulhof <gabriel.schulhof@intel.com>

view details

push time in 11 days

issue closednodejs/node

N-API: Type safety for napi_get_value_external/napi_unwrap

Is your feature request related to a problem? Please describe. napi_get_value_external is currently type-unsafe. It yields 32 or 64 arbitrary bits, with no guarantee as to whether they mean what the caller thinks they mean, nor which native module created the external. Even assuming that it's a pointer is unsafe and may result in segfault.

Describe the solution you'd like Please add a way to attach type information to values created by napi_create_external, and a way to check that type information when calling napi_get_value_external. The “type information” should be some sort of unique identifier generated by Node.js with an opaque C type, so that no two native modules can ever accidentally use the same type identifier for different types of external values.

Suggested API:

// An opaque identifier.
typedef struct napi_external_type__* napi_external_type;

// Creates a new napi_external_type.
// Each call to this function yields a different napi_external_type.
napi_status napi_create_external_type(
    napi_env env,
    napi_external_type* type
);

// Like napi_create_external, but takes a napi_external_type parameter.
// Attaches it to the created napi_value.
napi_status napi_create_typed_external(
    napi_env env,
    void* data,
    napi_finalize finalize_cb,
    void* finalize_hint,
    napi_external_type type,
    napi_value* result
);

// Like napi_get_value_external, but takes a napi_external_type parameter.
// Throws TypeError if the given napi_value has a different (or no) napi_external_type.
napi_status napi_get_value_typed_external(
    napi_env env,
    napi_value value,
    napi_external_type type,
    void** result
);

Describe alternatives you've considered Currently, I'm just assuming that napi_get_value_external gives me a pointer to something that's at least sizeof(void *) bytes long, and put a magic number at the beginning of the external data structure to identify its type. To make the magic number distinctive, it is a pointer to some data inside my module:

static const void *MAGIC = &MAGIC;

typedef struct {
    void *magic; // check if magic == MAGIC before use
    …
} my_data;

…

my_data *d;
napi_get_value_external(…, …, &d);
if (d->magic != MAGIC) {
    // bail
}

As I've said above, this will result in undefined behavior (probably segfault) if some other native module calls napi_create_external with a value that isn't a valid pointer, and that external value somehow gets fed to my native module. Nor is it actually guaranteed that my magic number won't happen to be at the beginning of some other module's unrelated data structure, though it is highly unlikely.

closed time in 11 days

argv-minus-one

PR closed nodejs/node

Reviewers
n-api: simplify bigint-from-word creation C++ n-api

Macro CHECK_MAYBE_EMPTY_WITH_PREAMBLE() does the work of checking the TryCatch and returning napi_pending_exception so this change reuses it for napi_create_bigint_words().

Signed-off-by: Gabriel Schulhof @gabrielschulhof

<!-- Thank you for your pull request. Please provide a description above and review the requirements below.

Bug fixes and new features should include tests and possibly benchmarks.

Contributors guide: https://github.com/nodejs/node/blob/master/CONTRIBUTING.md -->

Checklist

<!-- Remove items that do not apply. For completed items, change [ ] to [x]. -->

  • [x] make -j4 test (UNIX), or vcbuild test (Windows) passes
  • [x] tests and/or benchmarks are included
  • [x] commit message follows commit guidelines

<!-- Developer's Certificate of Origin 1.1

By making a contribution to this project, I certify that:

(a) The contribution was created in whole or in part by me and I have the right to submit it under the open source license indicated in the file; or

(b) The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate open source license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same open source license (unless I am permitted to submit under a different license), as indicated in the file; or

(c) The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it.

(d) I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the open source license(s) involved. -->

+29 -7

2 comments

3 changed files

gabrielschulhof

pr closed time in 11 days

pull request commentnodejs/node

n-api: simplify bigint-from-word creation

Landed in 0cc2a54a53831968d5c955cb6cc09a2c46bd75ea.

gabrielschulhof

comment created time in 11 days

push eventnodejs/node

Gabriel Schulhof

commit sha 0cc2a54a53831968d5c955cb6cc09a2c46bd75ea

n-api: simplify bigint-from-word creation Macro `CHECK_MAYBE_EMPTY_WITH_PREAMBLE()` does the work of checking the `TryCatch` and returning `napi_pending_exception` so this change reuses it for `napi_create_bigint_words()`. Signed-off-by: Gabriel Schulhof <gabriel.schulhof@intel.com> PR-URL: https://github.com/nodejs/node/pull/34554 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>

view details

push time in 11 days

pull request commentnodejs/node-addon-api

Make sure wrapcallback is used

CI:

Version Job Status
v15.x https://ci.nodejs.org/job/node-test-node-addon-api-new/2560/
v14.x https://ci.nodejs.org/job/node-test-node-addon-api-new/2561/
v12.x https://ci.nodejs.org/job/node-test-node-addon-api-new/2562/
v10.x https://ci.nodejs.org/job/node-test-node-addon-api-new/2563/
gabrielschulhof

comment created time in 12 days

push eventgabrielschulhof/node-addon-api

Gabriel Schulhof

commit sha b3cfa55a27c72f60fea899e6f3f9f2e545b91e45

test: add finalizer exception test

view details

Gabriel Schulhof

commit sha db0af19342bf10cbab24b06472a9c7f5d0842971

src: wrap finalizer callback

view details

push time in 12 days

pull request commentnodejs/node-addon-api

Make sure wrapcallback is used

Rebased on top of #773. I had to change the child process to examine the exception in the process' uncaughtException handler because it cannot be caught otherwise since https://github.com/nodejs/node/pull/34386.

gabrielschulhof

comment created time in 12 days

push eventgabrielschulhof/node-addon-api

Lovell Fuller

commit sha 40c79263421d21d92199cbbef0533f42a434d4f4

build: ensure paths with spaces can be used Ensure include path is relative to process working directory (PWD) This allows the use of parent paths that contain whitespace, plus keeps the approach consistent with that used by nan. (The previous approach of adding double quotes did not work as intended due to node-gyp removing these on the way through.) PR-URL: https://github.com/nodejs/node-addon-api/pull/757 Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com> Reviewed-By: Nicola Del Gobbo <nicoladelgobbo@gmail.com>

view details

NickNaso

commit sha 61c98463939630bb52438bb8ea1fb1fdf651af1c

Prepare release 3.0.1.

view details

Lovell Fuller

commit sha 6148fb4bcc30f2ab4c90b080488e787874c833b4

Synchronise Node.js versions in Appveyor Windows CI with Travis (#768)

view details

Gabriel Schulhof

commit sha 5af645f64900044971787b092567998be784dcb5

src: add Addon<T> class * separate out instance-related APIs from `ObjectWrap<T>` into a new class `InstanceWrap<T>` which then becomes a base class for `ObjectWrap<T>`. * Add `Addon<T>` class as a subclass of `InstanceWrap<T>`, reimplementing `Unwrap()` to retrieve the instance data using `GetInstanceData<T>()` of `Napi::Env` instead of `napi_unwrap()`. * Add macros `NODE_API_ADDON()` and `NODE_API_NAMED_ADDON()` to load an add-on from its `Addon<T>` subclass definition. Bindings created like this perform slightly worse than static ones in exchange for the benefit of having the context of a class instance as their C++ `this` object. This way, they avoid having to call `info.GetInstanceData<ClassName>()` in the bindings, which brings with it the risk that the wrong `ClassName` will end up in the template parameter thus resulting in a hard-to-track-down segfault. Static bindings can still be created and associated with the `exports` object and they can use `Napi::Env::GetInstanceData()` to retrieve the add-on instance. PR-URL: https://github.com/nodejs/node-addon-api/pull/749 Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>

view details

Gabriel Schulhof

commit sha 461e3640c6e3ca0eb429d5953c44d18ccb066bdc

test: string tests together * Use promises and async/await to ensure that one test finishes before another one starts. This prevents errors thrown in one test from appearing to originate from another test. * Perform garbage collection consistently, via `testUtil.runGCTests()`, to ensure that it is performed correctly and that its results are awaited. PR-URL: https://github.com/nodejs/node-addon-api/pull/773 Reviewed-By: Chengzhong Wu <legendecas@gmail.com> Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>

view details

Koki Nishihara

commit sha 4ce40d22a62d2c784b009179b74bfa1d0b5c810d

test: use assert.strictEqual() Fixes: https://github.com/nodejs/node-addon-api/issues/775 PR-URL: https://github.com/nodejs/node-addon-api/pull/777 Reviewed-By: Nicola Del Gobbo <nicoladelgobbo@gmail.com> Reviewed-By: Gabriel Schulhof <gabriel.schulhof@intel.com> Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>

view details

Gabriel Schulhof

commit sha 27bf245313a8fde63e92af79882d841ac086a44b

test: add finalizer exception test

view details

Gabriel Schulhof

commit sha c1cdb39e75756af9f85344fa3acdf4cd2d68691d

src: wrap finalizer callback

view details

push time in 13 days

push eventgabrielschulhof/node-addon-api

Koki Nishihara

commit sha 4ce40d22a62d2c784b009179b74bfa1d0b5c810d

test: use assert.strictEqual() Fixes: https://github.com/nodejs/node-addon-api/issues/775 PR-URL: https://github.com/nodejs/node-addon-api/pull/777 Reviewed-By: Nicola Del Gobbo <nicoladelgobbo@gmail.com> Reviewed-By: Gabriel Schulhof <gabriel.schulhof@intel.com> Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>

view details

push time in 13 days

create barnchgabrielschulhof/node-addon-api

branch : use-assert-strictEqual

created branch time in 13 days

PR closed nodejs/node-addon-api

test: use assert.strictEqual() blocked

Fix https://github.com/nodejs/node-addon-api/issues/775

+4 -4

5 comments

1 changed file

Nishikoh

pr closed time in 13 days

pull request commentnodejs/node-addon-api

test: use assert.strictEqual()

Landed in 4ce40d22a62d2c784b009179b74bfa1d0b5c810d.

Nishikoh

comment created time in 13 days

push eventnodejs/node-addon-api

Koki Nishihara

commit sha 4ce40d22a62d2c784b009179b74bfa1d0b5c810d

test: use assert.strictEqual() Fixes: https://github.com/nodejs/node-addon-api/issues/775 PR-URL: https://github.com/nodejs/node-addon-api/pull/777 Reviewed-By: Nicola Del Gobbo <nicoladelgobbo@gmail.com> Reviewed-By: Gabriel Schulhof <gabriel.schulhof@intel.com> Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>

view details

push time in 13 days

issue closednodejs/node-addon-api

test/threadsafe_function/threadsafe_function_existing_tsfn.js: use assert.strictEqual()

Currently it uses assert(typeof ... === 'number') but it would be more expressive in case of failure to use assert.strictEqual(typeof ..., 'number').

closed time in 13 days

gabrielschulhof

pull request commentnodejs/node-addon-api

test: use assert.strictEqual()

CI:

Version Job Status
v15.x https://ci.nodejs.org/job/node-test-node-addon-api-new/2552/
v14.x https://ci.nodejs.org/job/node-test-node-addon-api-new/2553/
v12.x https://ci.nodejs.org/job/node-test-node-addon-api-new/2554/
v10.x https://ci.nodejs.org/job/node-test-node-addon-api-new/2555/
Nishikoh

comment created time in 13 days

pull request commentnodejs/node-addon-api

test: use assert.strictEqual()

Rebased.

Nishikoh

comment created time in 13 days

push eventNishikoh/node-addon-api

Gabriel Schulhof

commit sha 461e3640c6e3ca0eb429d5953c44d18ccb066bdc

test: string tests together * Use promises and async/await to ensure that one test finishes before another one starts. This prevents errors thrown in one test from appearing to originate from another test. * Perform garbage collection consistently, via `testUtil.runGCTests()`, to ensure that it is performed correctly and that its results are awaited. PR-URL: https://github.com/nodejs/node-addon-api/pull/773 Reviewed-By: Chengzhong Wu <legendecas@gmail.com> Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>

view details

Koki Nishihara

commit sha a2f2232bafcafa8eb44b566892fe4292f6a8c8c7

test: use assert.strictEqual() https://github.com/nodejs/node-addon-api/issues/775

view details

Koki Nishihara

commit sha 9b26af9f2a413668b7a419b704d569c21d506f24

test: remove extra space

view details

push time in 13 days

push eventgabrielschulhof/node-addon-api

Gabriel Schulhof

commit sha 461e3640c6e3ca0eb429d5953c44d18ccb066bdc

test: string tests together * Use promises and async/await to ensure that one test finishes before another one starts. This prevents errors thrown in one test from appearing to originate from another test. * Perform garbage collection consistently, via `testUtil.runGCTests()`, to ensure that it is performed correctly and that its results are awaited. PR-URL: https://github.com/nodejs/node-addon-api/pull/773 Reviewed-By: Chengzhong Wu <legendecas@gmail.com> Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>

view details

push time in 13 days

more