Node.js V0.12 new features run multiple instances in a single process

Instance

It is often suggested that node.js can be embedded in other programs, especially allowing it to be integrated with other events and (at the same time) supporting multiple node execution contexts: that is, the ability to allow multiple node instances to coexist peacefully in the same process. Imagine, for example, a Node-webkit program where each window runs on its own node instance, and the windows are independent of each other. Or you can embed node in a cell phone or network switch to handle the routing logic of multiple connections, but only in a single process, and in the near future.

A client finds us and says that their program needs this kind of functionality. Their research has confirmed our contribution and expertise at node core and LIBUV, and decided to ask us for help. This is a fairly challenging order because node was-and still is-a single-threaded program that builds around the concept of a single event loop, storing various states with hundreds of global variables.

You can imagine how error-prone it is to install thread safety on such a code base, so that's not what we're doing-or we haven't. We want this change to be affordable for our customers, and taking this step forward can also help the community as a whole. By the way, if you find that you need to make some changes to node, but you have no time to study how to change, we can help!

Introducing multiple contexts

In fact, we implemented the ability to use multiple execution contexts in the same event loop in the node v0.12. Don't worry: There is no overt change for the average user, and everything is the same as before. But if you are an embedded developer, or a local add-on component author, please continue to look down!

"Multi-Context" is the first and most important cleanup task in submitting 756b622: It takes all the global variables and first removes the variables that don't need to be in the global context, and turns the rest into the properties of the execution situation. Although that is not enough to ensure thread safety, this first step is important.

The second step is to make node aware of the existence of multiple execution situations. The C + + runtime enters the V8 VM anywhere, ensuring that it enters the correct context. The following is a simple example:

function OnConnect () {
This.write (' get/http/1.1\r\n ' +
' host:strongloop.com\r\n ' +
' \ r \ n ');
This.pipe (process.stdout);
}
Require (' net '). Connect (, ' strongloop.com ', onconnect);

Execution-wise, almost should be like this:

<enter vm>
Connect ("strongloop.com");//kernel reports einprogress here
<leave vm>
< Wait for TCP handshake to complete>
<enter vm>
onconnect ();
<leave vm>

Back to the column page: http://www.bianceng.cnhttp://www.bianceng.cn/webkf/script/

The execution context may change between calls into the VM. So connect () it is necessary to remember the current situation and call OnConnect () to restore it. If this is not done, tracking bugs can become extremely difficult.

Fortunately, node can handle this automatically, embedding developers and local add-on components the author does not need to worry about this unless they want to use V8::function::call () instead of node::makecallback () to enter the VM to make the call.

If you are a local add-on author and want your attachment component to have the ability to identify situations, you need to:

* Instead of Node_module (), use 
node_module_context_aware (). Before:
 void Initialize (v8::handle<v8::object> exports) {
//...
}
Node_module (foo, Initialize)

After:

void Initialize (v8::handle<v8::object> exports,
v8::handle<v8::value> module,
v8::handle< V8::context> context) {
//...
}
Node_module_context_aware (foo, Initialize);

An initialization method that identifies a situation is invoked once for each context that is created in the embedded context. There is no cleanup function for each situation, which will ultimately be performed by Node::atexit (), but it is now a process-specific event. If this doesn't work for you, please submit a bug here.

There are several ways to turn global variables into properties of each situation, one of which is to declare an embedded data index for yourself, and to put everything in there.

These indexes do not yet have a global registry, so there is still the possibility of a conflict. Do you want to try a patch? At the same time pick an almost large random number (such as 2^10 to 2^16), but not too extreme: V8 uses a non-sparse matrix as the internal storage of the embedded index. Declaring the index as 1 << 29 consumes a lot of memory!

How much work remains to be done?

There are also rough edges to be polished: process.chdir () changes the working directory of all situations, but it should actually change the working directory of the context in which it was invoked; loading additional components from multiple contexts there are boundary conditions, and so on. But it's a patchwork of work that's perfect. The basic framework is in place, and the company that sponsored us to develop the multiple situational features has successfully used it. More importantly, it paves the way for multi-threaded multiple leases. That's not likely to happen before node v0.12, but we might see it in Node v1.0 or another version-as long as we dare!