At the collaborator summit in Berlin, the behaviour of
`worker.terminate()` was discussed.
In particular, switching from a callback-based to a Promise-based API
was suggested. While investigating that possibility later, it was
discovered that `.terminate()` was unintentionally synchronous up
until now (including calling its callback synchronously).
Also, the topic of its stability has been brought up. I have performed
two manual reviews of the native codebase for compatibility with
`.terminate()`, and performed some manual fuzz testing with the test
suite. At this point, bugs with `.terminate()` should, in my opinion,
be treated like bugs in other Node.js features.
(It is possible to make Node.js crash with `.terminate()` by messing
with internals and/or built-in prototype objects, but that is already
the case without `.terminate()` as well.)
This commit:
- Makes `.terminate()` an asynchronous operation.
- Makes `.terminate()` return a `Promise`.
- Runtime-deprecates passing a callback.
- Removes a warning about its stability from the documentation.
- Eliminates an unnecessary extra function from the C++ code.
A possible alternative to returning a `Promise` would be to keep the
method synchronous and just drop the callback. Generally, providing
an asynchronous API does provide us with a bit more flexibility.
Refs: https://github.com/nodejs/summit/issues/141
PR-URL: https://github.com/nodejs/node/pull/28021
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Tiancheng "Timothy" Gu <timothygu99@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Stop automatically setting servername in https.request() if the target
host is specified with an IP address. Doing so is invalid, and triggers
a deprecation warning. It is still possible to send an IP address as a
servername if its required, but it needs to be explicity configured, it
won't happen automatically.
PR-URL: https://github.com/nodejs/node/pull/28209
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Yongsheng Zhang <zyszys98@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Historically `error.errno` of system errors thrown by Node.js
can sometimes be the same as `err.code`, which are string
representations of the error numbers. This is useless and incorrect,
and results in an information loss for users since then they
will have to resort to something like
`process.binding('uv'[`UV_${errno}`])` to get to the numeric
error codes.
This patch corrects this behavior by always setting `error.errno`
to be negative numbers. For fabricated errors like `ENOTFOUND`,
`error.errno` is now undefined since there is no numeric equivalent
for them anyway. For c-ares errors, `error.errno` is now undefined
because the numeric representations (negated) can be in conflict
with libuv error codes - this is fine since numeric codes was
not available for c-ares errors anyway.
Users can use the public API `util.getSystemErrorName(errno)`
to retrieve string codes for these numbers.
PR-URL: https://github.com/nodejs/node/pull/28140
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com>
The report shows CPU consumption %, but without the number of CPU cores,
a consumer cannot tell if the percent (given across all cores) is
actually problematic. E.g., 100% on one CPU is a problem, but 100% on
four CPUs is not necessarily.
This change adds CPU information (similar to `os.cpus()`) to the report
output. Extra info besides the count is also provided as to avoid future
breaking changes in the eventuality that someone needs it; changing the
datatype of `header.cpus` would be breaking.
PR-URL: https://github.com/nodejs/node/pull/28188
Refs: https://github.com/nodejs/diagnostics/issues/307
Reviewed-By: Sam Roberts <vieuxtech@gmail.com>
Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com>
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
- Extend the aliased buffer for stats objects to contain
the entire time spec (seconds and nanoseconds) for the time
values instead of calculating the milliseconds in C++ and
lose precision there.
- Calculate the nanosecond-precision time values in JS and expose
them in BigInt Stats objects as `*timeNs`. The
millisecond-precision values are now calculated from the
nanosecond-precision values.
PR-URL: https://github.com/nodejs/node/pull/21387
Reviewed-By: Jeremiah Senkpiel <fishrock123@rocketmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Gus Caplan <me@gus.host>
Refactor the C++ code for creating `MessagePort`s to skip calling the
constructor and instead directly instantiating the `InstanceTemplate`,
and always throw an error from the `MessagePort` constructor.
This aligns behaviour with the web, and creating single `MessagePort`s
does not make sense anyway.
PR-URL: https://github.com/nodejs/node/pull/28032
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Tiancheng "Timothy" Gu <timothygu99@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Using `assert.throws()` or `assert.rejects()` in combination with
validation function can be very powerful. Using them by returning
any value besides `true` makes debugging very difficult though
because there's no context or reason why the error validation failed.
Thus, it is recommended to throw an error in such cases instead of
returning anything besides `true`.
PR-URL: https://github.com/nodejs/node/pull/27781
Reviewed-By: Rich Trott <rtrott@gmail.com>
When implementing a pool for Worker threads, the correlation between
posting tasks and getting their results may get lost, depending on
the implementation.
The `AsyncResource` API is the primary way to solve that issue,
so link it from the recommendation in the worker docs.
(This was brought up at the collaborator summit in Berlin.)
PR-URL: https://github.com/nodejs/node/pull/28023
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com>
