initialized
At the moment in node, isolates are allocated and initialized in a
single step. Directly after that step the IsolateData* is initialized
which instantly attempts to use the isolate and registers the isolate
data on the node platform.
One of those two things is good, we need to register the IsolateData
on the platform but we we don't want the isolate to be used.
In gin (chromium) the isolate creation is split up into two steps,
allocation and initialization. Chrome wants a task runner to be
obtainable from the platform after allocation but before initialization.
In order for this to work the IsolateData* needs to be registered with
the platform so we need this patch to allow us to control usage of the
Isolate inside IsolateData so we can register the IsolateData manually
and be responsible for setting up private properties after the isolate
is initialized.
Refs: https://chromium-review.googlesource.com/c/chromium/src/+/1015020
Note: This is a pretty hefty patch and I'd love to reduce it at some
point, it has counterparts in both Electron and Electron's gin patches.
This commit adds two new exposed methods to `node.cc`, `InitGeneric` and
`LoadEnvironmentGeneric` that allow for control of which mode Node
should run, which i have called `standalone_mode` and
`upstream_node_mode`. Default behavior of `Init` and `LoadEnvironment`
remain the same.
We have 3 modes when running Node in Electron:
1. In the main process, we want to have a full Node environment, but
with signal handlers and other low level things disabled
2. In renderer process, we want Node to reuse the web page's context
3. In `ELECTRON_RUN_AS_NODE`, we want Node to run as it runs officially
by default
For modes 1 and 3, we have Node create a new V8 context with a Node
Environment on it. However, for mode 2, since the V8 context is created
by blink for web frames and web workers we make Node create the Node
Environment on the V8 context of blink, so no new V8 context is created.
As a result, a renderer process may have multiple Node Environments in it.
Blink overrides ArrayBuffer's allocator with its own one, while Node
simply uses malloc and free. This commit prevents the crash that would
be resultant of mixing them together.
blink can not recognize external strings from Node, and it will crash
when encountered one, for example executing `window.string_decoder`.
Note that the values are still using external strings, but making them
normal string may have negative affects on performance, and it is very
unlikely they would be passed to blink.
This commit exposes InternalCallbackScope in order to allow us access to kAllowEmptyResource for usage https://github.com/electron/electron/blob/master/atom/common/api/atom_bindings.cc\#L108. We should look to accomplish this another way so we no longer need to do this, as in verbose mode the regular CallBack Scope doesn't swallow errors and so we can otherwise use it.
Instantiate redefined version of the internalModuleStat function
(see lib/common/asar.js in the electron/electron repo). For some reason
this has to be done after the upgrade to the Node.js v8.7.0. `const
internalModuleStat` in the very beginning of the file holds a reference
to a native Node.js implementation of the function.
Node inspector initialization happens in a different start-up function in node.cc, which we don't call in Electron. This allows for us to use the inspector agent in electron/atom/browser/node_debugger.cc
Node required tracing controller to be initialized, otherwise a crash would occur. Changed in concert with 0e5b6f9300\#diff-0cdfa12fff513e022fac830c6af9c19a
We include node_internals.h as a part of node_includes.h in electron, so we run into conflicts with trace headers from chromium. To mitigate that, we removed trace_event.h from node_internals.h and just added it to the required places in node.
This is a requirement for electron/electron#8815, which exposes some builtin
modules to sandboxed renderers.
(cherry picked from commit 4c058a6cb5331eef1c7f51c042dd074a2d4f9234)
On Windows, if code accesses process.stdin an exception will happen because there is no stdin pipe in GUI programs on Windows. This commit fixes that issue by creating a dummy stream
Electron's Node Integration works by listening to Node's backend file descriptor in a separate thread; when an event is ready the backend file descriptor will trigger a new event for it, and the main thread will then iterate the libuv loop. For certain operations (ex. adding a timeout task) the backend file descriptor isn't informed, & as a result the main thread doesn't know it needs to iterate the libuv loop so the timeout task will never execute until something else trigger a new event. This commit should be removed when https://github.com/libuv/libuv/pull/1921 is merged
When forking a child script, we setup a special environment to make the Electron binary run like the upstream node. On Mac, we use the helper app as node binary.
This commit prevents console windows from being spawned when creating processes to better align with what Windows users expect and should be removed when upgrading to a version that includes https://github.com/nodejs/node/pull/21316