-
Notifications
You must be signed in to change notification settings - Fork 30.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[wip] src, inspector: support opted-in VM contexts #14231
Changes from all commits
ff88cf4
9f12ee8
a08b03e
2d9272c
f1ca818
a8ebfb5
fe7c4a5
0352a48
06f635b
fc7d408
a0c6f68
15a8ff8
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -59,6 +59,11 @@ changes: | |
`cachedData` property of the returned `vm.Script` instance. | ||
The `cachedDataProduced` value will be set to either `true` or `false` | ||
depending on whether code cache data is produced successfully. | ||
* `contextifiedSandbox` {Object} A [contextified][] sandbox to associate with | ||
the current script. This does not bind the created script to this context | ||
(i.e. `runInContext` still works with all contexts), but merely informs V8 | ||
(and V8 inspector) that the script is associated with the context. Defaults | ||
to the current context. | ||
|
||
Creating a new `vm.Script` object compiles `code` but does not run it. The | ||
compiled `vm.Script` can be run later multiple times. It is important to note | ||
|
@@ -94,12 +99,28 @@ changes: | |
event that have been attached via `process.on("SIGINT")` will be disabled | ||
during script execution, but will continue to work after that. | ||
If execution is terminated, an [`Error`][] will be thrown. | ||
* `doNotInformInspector` {boolean} If `true`, do not try to attach the | ||
context to inspector. Debugging with `--inspect` will not work for code in | ||
the context in that case. | ||
|
||
|
||
Runs the compiled code contained by the `vm.Script` object within the given | ||
`contextifiedSandbox` and returns the result. Running code does not have access | ||
to local scope. | ||
|
||
By default, this function checks if inspector was already aware of the context | ||
(if support for inspector is available in the Node.js build). If not, and if | ||
`doNotInformInspector` is not specified, this function attaches it to inspector | ||
using [`inspector.attachContext()`][], and detaches it before returning. | ||
However, *it is still recommended that you handle context attachment and | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Please avoid the use of |
||
detachment manually,* since: | ||
|
||
1. Asynchronous code running in the context would still not have inspector | ||
debugging support, if relying on automatic attachment provided by this | ||
function. | ||
2. Attaching and detaching per `runInContext()` run can have a significant | ||
performance cost if this is done for the same context again and again. | ||
|
||
The following example compiles code that increments a global variable, sets | ||
the value of another global variable, then execute the code multiple times. | ||
The globals are contained in the `sandbox` object. | ||
|
@@ -149,11 +170,23 @@ added: v0.3.1 | |
* `timeout` {number} Specifies the number of milliseconds to execute `code` | ||
before terminating execution. If execution is terminated, an [`Error`][] | ||
will be thrown. | ||
* `doNotInformInspector` {boolean} If `true`, do not try to attach the | ||
context to inspector. Debugging with `--inspect` will not work for code in | ||
the context in that case. | ||
|
||
First contextifies the given `sandbox`, runs the compiled code contained by | ||
the `vm.Script` object within the created sandbox, and returns the result. | ||
Running code does not have access to local scope. | ||
|
||
By default, if support for inspector is available in the Node.js build, and if | ||
`doNotInformInspector` is not specified, this function attaches the new context | ||
to inspector using [`inspector.attachContext()`][], and detaches it before | ||
returning. However, if debugging supported is desired, *it is recommended that | ||
you handle context creation, attachment to inspector, and detachment from | ||
inspector manually,* since asynchronous code running in the context would still | ||
not have inspector debugging support, if relying on automatic attachment | ||
provided by this function. | ||
|
||
The following example compiles code that sets a global variable, then executes | ||
the code multiple times in different contexts. The globals are set on and | ||
contained within each individual `sandbox`. | ||
|
@@ -284,12 +317,28 @@ Returns `true` if the given `sandbox` object has been [contextified][] using | |
* `timeout` {number} Specifies the number of milliseconds to execute `code` | ||
before terminating execution. If execution is terminated, an [`Error`][] | ||
will be thrown. | ||
* `doNotInformInspector` {boolean} If `true`, do not try to attach the | ||
context to inspector. Debugging with `--inspect` will not work for code in | ||
the context in that case. | ||
|
||
The `vm.runInContext()` method compiles `code`, runs it within the context of | ||
the `contextifiedSandbox`, then returns the result. Running code does not have | ||
access to the local scope. The `contextifiedSandbox` object *must* have been | ||
previously [contextified][] using the [`vm.createContext()`][] method. | ||
|
||
By default, this function checks if inspector was already aware of the context | ||
(if support for inspector is available in the Node.js build). If not, and if | ||
`doNotInformInspector` is not specified, this function attaches it to inspector | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Same recommended rewording as my above comment. |
||
using [`inspector.attachContext()`][], and detaches it before returning. | ||
However, *it is still recommended that you handle context attachment and | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Here too... please avoid |
||
detachment manually,* since: | ||
|
||
1. Asynchronous code running in the context would still not have inspector | ||
debugging support, if relying on automatic attachment provided by this | ||
function. | ||
2. Attaching and detaching per `runInContext()` run can have a significant | ||
performance cost if this is done for the same context again and again. | ||
|
||
The following example compiles and executes different scripts using a single | ||
[contextified][] object: | ||
|
||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Lots of negatives in here, which might get confusing. How about something like this: