In case a worker would spawn a new subprocess with process.env, NODE_UNIQUE_ID
would have been a part of the env. Making the new subprocess believe it is a
worker, this would result in some confusion if the subprocess where to listen to
a port, since the server handle request would then be relayed to the worker.
This patch removes the NODE_UNIQUE_ID flag from process.env on startup so any
subprocess spawned by a worker is a normal process with no cluster stuff.
There are some paths here that led to dangling contexts. By being smarter with
handle management we can get rid of all the cleanup code and fix those issues.
This is a backport of commit 7063575.
Before this commit, process._getActiveHandles() returned a list of internal
handles. Now, it returns the user objects that handles are attached to.
For example, a tcp_wrap handle will now return its parent net.Socket object.
It works for all handle types except timers because timer handles are shared
across multiple user objects.
* process._getActiveHandles() returns a list containing all active handles
(timers, sockets, etc.) that have not been unref'd.
* process._getActiveRequests() returns a list of active requests (in-flight
actions like connecting to a remote host, writing data to a socket, etc.).
Share persistent strings process_symbol and domain_symbol across compilation
units. Avoids redefinition errors when src/node.cc includes src/req_wrap.h.
Prevents accidental inheritance by child processes. If the child process is a
node process, it would try to set up a channel with the parent and consequently
never quit because the channel kept the event loop alive.
Fixes#3240.
This patch now reports the proper throw call site for exceptions
triggered within process.nextTick. So instead of this:
node.js:201
throw e; // process.nextTick error, or 'error' event on first tick
^
You will now see:
mydir/myscript.js:15
throw new Error('My Error');
^
From my testing this patch causes no performance regressions, but does
greatly simplify processing the nextTickQueue.
The crashes in debug mode after adding Locker are *not* caused by
Locker. Locker is merely exposing issues that already existed. Some of
these issues have since been fixed in 70635753.
This reverts commit 407181538b.
This reapplies commit 9a6012edd9.
Conflicts:
src/node.cc
Upon "normal" exiting of Node (i.e. the event loop completes naturally),
the "code" parameter was not being passed to the "exit" event listeners.
Be consistent. Tests included.
There are some paths here that led to dangling contexts. By being
smarter with handle management we can get rid of all the cleanup code
and fix those issues.
Reusing the same logic for both places for the behavior is consistent.
For example:
$ ./node -p -e "'Hello World'"
Hello World
$ echo "'Hello World'" | ./node -p
Hello World