Implementing the inspector session object as an async resource causes
unwanted context change when a breakpoint callback function is being
called. Modelling the inspector api without the AsyncWrap base class
ensures that the callback has access to the AsyncLocalStorage instance
that is active in the affected user function.
See `test-inspector-async-context-brk.js` for an illustration of the
use case.
PR-URL: https://github.com/nodejs/node/pull/51501
Reviewed-By: Gerhard Stöbich <deb2001-github@yahoo.de>
Reviewed-By: Stephen Belanger <admin@stephenbelanger.com>
PR-URL: https://github.com/nodejs/node/pull/49884
Reviewed-By: Yagiz Nizipli <yagiz.nizipli@sentry.io>
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
Reviewed-By: Stephen Belanger <admin@stephenbelanger.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Co-authored-by: Daniel Lemire <daniel@lemire.me>
PR-URL: https://github.com/nodejs/node/pull/50322
Reviewed-By: Jacob Smith <jacob@frende.me>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Geoffrey Booth <webadmin@geoffreybooth.com>
PR-URL: https://github.com/nodejs/node/pull/48817
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: Matthew Aitken <maitken033380023@gmail.com>
Reviewed-By: Stephen Belanger <admin@stephenbelanger.com>
None of these constants have any effect in recent OpenSSL versions, not
even in Node.js release lines that still use OpenSSL 1.1.1.
It is likely rare that these options are still used (intentionally), and
removing them is unlikely to break any existing applications. These
constants can only be passed to the secureOptions option of
tls.createSecureContext() and related APIs, and a value of undefined
will be ignored. Similarly, if a bitwise combination of multiple options
is used, undefined constants will not change the behavior because
(a | undefined | b) === (a | b) for (small) integers a and b.
Refs: https://github.com/nodejs/node/pull/46954
Refs: https://github.com/nodejs/node/pull/47066
PR-URL: https://github.com/nodejs/node/pull/47073
Reviewed-By: Filip Skokan <panva.ip@gmail.com>
Reviewed-By: Rafael Gonzaga <rafael.nunu@hotmail.com>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
This constant was likely introduced for feature detection, but it has
been pointless for a long time.
1. I am not aware of any possible Node.js build configuration (on any
recent/supported release line) that would have crypto.constants but
not crypto.constants.ALPN_ENABLED.
2. There is no evidence of this constant being used for feature
detection in the ecosystem. In fact, both internal and external type
definitions for crypto.constants simply assume that the constant
exists.
3. There is no good reason for any modern TLS stack to not support ALPN.
It looks like ALPN might have been optional in much earlier versions
of OpenSSL, but all recent versions of OpenSSL unconditionally
support ALPN as far as I can tell.
Refs: https://github.com/nodejs/node/pull/46956
PR-URL: https://github.com/nodejs/node/pull/47028
Reviewed-By: Filip Skokan <panva.ip@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
`contextify_global_private_symbol` is no longer used. It was used
to hold a new context's global object, but the approach has been
changed to hold a ContextifyContext wrapper using
`contextify_context_private_symbol`.
Signed-off-by: Daeyeon Jeong <daeyeon.dev@gmail.com>
PR-URL: https://github.com/nodejs/node/pull/45128
Refs: https://github.com/nodejs/node/pull/44796
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Mohammed Keyvanzadeh <mohammadkeyvanzade94@gmail.com>
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Reviewed-By: Juan José Arboleda <soyjuanarbol@gmail.com>
It doesn't make sense from a performance perspective to retain an
arraybuffer with the ALPN byte string and look it up as a property on
the JS context object for every TLS handshake.
Store the byte string in the C++ TLSWrap object instead. That's both
a lot faster and a lot simpler.
PR-URL: https://github.com/nodejs/node/pull/44875
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Tobias Nießen <tniessen@tnie.de>
This would prevent manual writes to the _exiting JS property on the
process object by passing the data directly via a typed array for
performance.
This change partially addresses this TODO:
3d575a4f1b/src/api/hooks.cc (L68-L71)
Signed-off-by: Darshan Sen <raisinten@gmail.com>
PR-URL: https://github.com/nodejs/node/pull/43883
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Promises are never destroyed manually therefore it's not needed to
attach an object to track if destroy hook was called already.
PR-URL: https://github.com/nodejs/node/pull/42402
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Mohammed Keyvanzadeh <mohammadkeyvanzade94@gmail.com>
PR-URL: https://github.com/nodejs/node/pull/40222
Reviewed-By: Tobias Nießen <tniessen@tnie.de>
Reviewed-By: Evan Lucas <evanlucas@me.com>
Reviewed-By: Zijian Liu <lxxyxzj@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Michael Dawson <midawson@redhat.com>
PR-URL: https://github.com/nodejs/node/pull/40222
Reviewed-By: Tobias Nießen <tniessen@tnie.de>
Reviewed-By: Evan Lucas <evanlucas@me.com>
Reviewed-By: Zijian Liu <lxxyxzj@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Michael Dawson <midawson@redhat.com>
