When a Worker is terminated, its own handle and the public
`MessagePort` are `.ref()`’ed, so that all relevant events,
including the `'exit'` events, end up being received.
However, this is problematic if messages end up being queued
from the Worker between the beginning of the `.terminate()` call
and its completion, and there are no `'message'` event handlers
present at that time. In that situation, currently the messages
would not end up being processed, and since the MessagePort
is still `.ref()`’ed, it would keep the event loop alive
indefinitely.
To fix this:
- Make sure that all messages end up being received by
`drainMessagePort()`, including cases in which the port had
been stopped (i.e. there are no `'message'` listeners) and
cases in which we exceed the limit for messages being processed
in one batch.
- Unref the Worker’s internal ports manually after the Worker
has exited.
Either of these solutions should be solving this on its own,
but I think it makes sense to make sure that both of them
happen during cleanup.
PR-URL: https://github.com/nodejs/node/pull/37319
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
There is no reason to hide FIPS functionality behind build flags.
OpenSSL always provide the information about FIPS availability via
`FIPS_mode()` function.
This makes the user experience more consistent, because the OpenSSL
library is always queried and the `crypto.getFips()` always returns
OpenSSL settings.
Fixes#34903
PR-URL: https://github.com/nodejs/node/pull/36341
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Michael Dawson <midawson@redhat.com>
Reviewed-By: Daniel Bevenius <daniel.bevenius@gmail.com>
* Update the user timing implementation to conform to
User Timing Level 3.
* Reimplement user timing and timerify with pure JavaScript
implementations
* Simplify the C++ implementation for gc and http2 perf
* Runtime deprecate additional perf entry properties
in favor of the standard detail argument
* Disable the `buffered` option on PerformanceObserver,
all entries are queued and dispatched on setImmediate.
Only entries with active observers are buffered.
* This does remove the user timing and timerify
trace events. Because the trace_events are still
considered experimental, those can be removed without
a deprecation cycle. They are removed to improve
performance and reduce complexity.
Old: `perf_hooks/usertiming.js n=100000: 92,378.01249733355`
New: perf_hooks/usertiming.js n=100000: 270,393.5280638482`
PR-URL: https://github.com/nodejs/node/pull/37136
Refs: https://github.com/nodejs/diagnostics/issues/464
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
The following warnings are disabled:
- C4065 in node_revert.h: there are no security reversions on the master
branch.
- C4003 in base64-inl.h: a macro is used four times, only once without
parameters.
PR-URL: https://github.com/nodejs/node/pull/37334
Reviewed-By: James M Snell <jasnell@gmail.com>
Adds a new `perf_hooks.createHistogram()` API for creating histogram
instances that allow user recording.
Makes Histogram instances cloneable via MessagePort. This allows, for
instance, an event loop delay monitor to be running on the main thread
while the histogram data can be monitored actively from a worker thread.
Signed-off-by: James M Snell <jasnell@gmail.com>
PR-URL: https://github.com/nodejs/node/pull/37155
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Unlike JS-only modules, native add-ons are always associated with a
dynamic shared object from which they are loaded. Being able to
retrieve its absolute path is important to native-only add-ons, i.e.
add-ons that are not themselves being loaded from a JS-only module
located in the same package as the native add-on itself.
Currently, the file name is obtained at environment construction time
from the JS `module.filename`. Nevertheless, the presence of `module`
is not required, because the file name could also be passed in via a
private property added onto `exports` from the `process.dlopen`
binding.
As an attempt at future-proofing, the file name is provided as a URL,
i.e. prefixed with the `file://` protocol.
Fixes: https://github.com/nodejs/node-addon-api/issues/449
PR-URL: https://github.com/nodejs/node/pull/37195
Co-authored-by: Michael Dawson <mdawson@devrus.com>
Reviewed-By: Michael Dawson <midawson@redhat.com>
This commit introduces a mutex field on the ManagedEVPPKey class
intended to be used when multiple threads require access to an OpenSSL
EVP_PKEY object. The motivation for this came from the work being done
to upgrade Node.js to OpenSSL 3.0.
OpenSSL objects, like EVP_PKEY, are not thread safe (see refs for
details). In versions prior to OpenSSL 3.0 this was not noticeable and
did not cause any issues (like incorrect logic or crashes), but with
OpenSSL 3.0 this does cause issues if access to an EVP_PKEY instance is
required from multiple threads without locking.
In OpenSSL 3.0 when the evp_pkey_downgrade function is called, which
downgrades an EVP_PKEY instance to a legacy version, it will clear all
the fields of EVP_PKEY struct except the lock (#13374). But this also
means that keymgmt and keydata will also be cleared, which other parts
of the code base depends on, and those calls will either fail to export
the key (returning null) or crash due to a segment fault.
This same code works with OpenSSL 1.1.1 without locking and I think this
is because there is no downgrade being done in OpenSSL 1.1.1. But even
so, as far as I can tell there are no guarantees that these object are
thread safe in 1.1.1 either and should be protected with a lock.
PR-URL: https://github.com/nodejs/node/pull/36825
Refs: https://github.com/openssl/openssl/pull/13374
Refs: https://github.com/openssl/openssl/pull/13374
Refs: https://github.com/openssl/openssl/issues/2165)
Refs: https://www.openssl.org/blog/blog/2017/02/21/threads
Reviewed-By: James M Snell <jasnell@gmail.com>
1. Put the v8 binding data class into a header so we can reuse
the class definition during deserialization.
2. Put the v8 binding code into node::v8_utils namespace for
clarity.
3. Move the binding data property initialization into its
constructor so that we can reuse it during deserialization
4. Reorder the v8 binding initialization so that we don't
unnecessarily initialize the properties in a loop
PR-URL: https://github.com/nodejs/node/pull/37112
Refs: https://github.com/nodejs/node/pull/36943
Reviewed-By: Juan José Arboleda <soyjuanarbol@gmail.com>
Previously, this was a per-class string constant for BindingData
which is used as keys for identifying these objects in the binding
data map. These are just type names of the BindingData.
This patch renames the variable to type_name so that
we can generalize this constant for other BaseObjects and use
it for debugging and logging the types of other BaseObjects.
PR-URL: https://github.com/nodejs/node/pull/37112
Refs: https://github.com/nodejs/node/pull/36943
Reviewed-By: Juan José Arboleda <soyjuanarbol@gmail.com>
Add more context around the TODO change required for achieving the
task. When destructuring the isolate and environment_vars from the
environment object, it is leading to recursive dependency and thus not
able to refactor it in a better way.
PR-URL: https://github.com/nodejs/node/pull/37140
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Reviewed-By: Pooja D P <Pooja.D.P@ibm.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Using the reset does a double allocation and is error prone if some
exception occured which is very unlikely but can happen. make_shared_ptr
gives hedge over this and handle the failure in allocation.
PR-URL: https://github.com/nodejs/node/pull/37139
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
This patch
1. Refactors the bootstrap routine of the main instance so that
when --no-node-snapshot is used,
Environment::InitializeMainContext() will only be called once
(previously it would be called twice, which was harmless for now
but not ideal).
2. Mark the number of BaseObjects in RunBootstrapping() when creating
the Environment from scratch and in InitializeMainContext() when
the Environment is deserialized. Previously the marking was done in
the Environment constructor and InitializeMainContext() respectively
for the cctest which was incorrect because the cctest never uses
an Environment that's not bootstrapped. Also renames the mark
to base_object_created_after_bootstrap to reflect what it's
intended for.
PR-URL: https://github.com/nodejs/node/pull/37113
Refs: https://github.com/nodejs/node/pull/36943
Reviewed-By: James M Snell <jasnell@gmail.com>
Node 15 prior to this commit will not compile if openssl is built with
no-psk. Compiling emits an error like this:
```
crypto_tls.cc:(.text+0x4c27): undefined reference to
`node::crypto::TLSWrap::SetCACerts(node::crypto::SecureContext*)'
```
Blame on crypto_tls.cc shows the file was created in a refactor. Before
that refactor SetCACerts was defined outside OPENSSL_NO_PSK ifndef.
PR-URL: https://github.com/nodejs/node/pull/36881
Fixes: https://github.com/nodejs/node/issues/36464
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Richard Lau <rlau@redhat.com>
Anna Henningsen