Node v0.8 roadmap
- Move the remaining platform functions from src/platform-*.cc into
- Get rid of WAF. All platforms will build using GYP. (Ben, Ryan)
- Isolates. Node will allow users to spawn "child processes" that actually
run in a thread. We have to get rid of all the global variables in node.
Compiled extensions need know which isolate they're targeting, and we need
to decide if we want to load the extension multiple times or just once.
Also, some changes to libuv are necessary, since we will have to completely
clean up a loop. Finally we'll have to deal with debugging a multi-threaded
node process. (Ben, Ryan)
- Domains. Domains provide a lightweight isolation mechanism for all i/o
related to a particular network connection (e.g. an incoming http request).
If an unhandled error is encountered, all i/o local to that particular
domain is canceled and all handles are cleaned up. An experimental
implementation can be found at https://github.com/joyent/node/commits/domains.
Some of the early work for domains will be used in Isolate support (e.g.
cleaning up handles when an Isolate is killed) (Bert, Ryan)
- Better allocator. Currently node uses a memory pool allocator to provide
read buffers for incoming data streams. This allocator is only
reasonably efficient for network connections and local pipes on Unix, and on
Windows when zero reads are used. For file i/o and buffered reads on Windows
we need a better story. (Igor)
- Addons. We need to define an easy and suggested way of building
extensions, which should be similar across all supported platforms. (Everyone)
> - Isolates. Node will allow users to spawn "child processes" that actually
> run in a thread. We have to get rid of all the global variables in node.
> Compiled extensions need know which isolate they're targeting, and we need
> to decide if we want to load the extension multiple times or just once.
> Also, some changes to libuv are necessary, since we will have to completely
> clean up a loop. Finally we'll have to deal with debugging a multi-threaded
> node process. (Ben, Ryan)
I'm wondering what the plan is intended use is for isolates.
If I remember correctly, the main reason we want to use them to get away from using multiple system processes as we do now for processing concurrency, mainly because Windows really wants you to use threads.
If that is the case, will the current cluster APIs, and most node APIs in general, remain unchanged and as "dumb" or "smart" about clustering as they are today? For example: using cluster today you will have an http module per process with a separate pool global to that process. When I see notes like "remove all global variables" I wonder if there is a plan to change this behavior.
stream.write has no callback. Just saying.
jmar: do you mean "if a CB is not specified, return a promise instead" kind of approach?
Job Board: http://jobs.nodejs.org/
Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nod...@googlegroups.com
To unsubscribe from this group, send email to
For more options, visit this group at
It's not off the roadmap but it's not a "must have" for 0.8. This is
something Isaac will be looking at after NPM is fully functioning on
Windows. Bring your API proposals to him.
I think what Ryan meant was that "promisey" objects were going to go back in to core and that we may want to standardize them a bit more.We have several domain specific objects, which are streams, which also resolve several states at some time in the future. Files, sockets, and http among them. While the stream interface is specified there are several other states in the objects that is not specified nor is the interface entirely implemented for people to extend.
Also, in the future there are optimizations we can make if we are all in the same process.
For instance, WebWorkers are shared nothing as well but Chrome has done some recent work to allow you to pass messages to them by reference rather than suffering serialization.
There is no memory sharing between isolates.
We're giving people the option of starting a new Node either as a
standalone process or as a new thread/isolate. Most people will want
to continue using processes as their method of parallelizing because
it's most robust. However some people will want to use threads because
with an addon they can do fancy synchronization between the isolates.
The isolates feature is to enable advanced parallelizing techniques in