2011-11-19

The Node.js v0.8 roadmap

Ryan Dahl has posted the roadmap for version 0.8 of Node.js. The following sections describe the highlights.

Isolates (child processes)

Quoting the announcement:
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.
github.com/joyent/node/issues/2133
How does this relate to Web Workers? Quoting Paddy Byers:
Web workers are a way of running pure javascript in a separate thread or process, with the results passed back to the requesting thread via message passing. The idea is that the web worker can perform work that is computationally intensive and synchronous, which would otherwise block the event thread, in a separate thread.

child_process.fork() spawns an entirely new instance of node. That means that, in addition to being a separate javascript execution environment, it gets to have all of the node functionality; to load modules, and to use all of the system functionality that you get as a result. It also has its own event loop so it is a fully-fledged and independent entity with its own lifecycle- not a slave of some other event thread. It can in turn spawn new instances, and can outlive the instance that created it.

So the objectives are different and the functionality beyond pure javascript is different. However, they provide an "equivalent" kind of separation of javascript state and flow control, and similar methods of communication between parent and child.

To summarize: You would probably use Web Workers to parallelize an algorithm and child processes for longer-term jobs.

Domains

Quoting the announcement:
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. […]
github.com/joyent/node/issues/2134

Addons

Quoting the announcement:
We need to define an easy and suggested way of building extensions, which should be similar across all supported platforms.
github.com/joyent/node/issues/2136
Quoting the Node.js documentation on addons:
Addons are dynamically linked shared objects. They can provide glue to C and C++ libraries.

4 comments:

Thomas Eichberger said...

What do you think about this article? Is the author right?

http://teddziuba.com/2011/10/node-js-is-cancer.html

Axel Rauschmayer said...

In my experience, there is a high correlation between people using swearwords such as “shit” and them being wrong. And the article is indeed poorly argued flamebait. The following is a good response to it:
http://blog.brianbeck.com/post/10967024222/node-js-cures-cancer

Jake Verbaten said...

The author is spreading misinformation.

There are two points in his article

 - node.js is not a silver bullet
 - javascript sucks.

The first is correct because nothing is a silver bullet. He's attacking how easy it is to misunderstand what it [means to be non blocking in node.js][1].

The second is simply opinionated. It would be the same as me saying ".NET sucks" and can thus be ignored as personal opinion

  [1]: http://raynos.org/blog/13/What-it-means-to-be-non-blocking-in-node.

Steve Howe said...

So he's spreading misinformation based on something that it's "widely known" and the other one is "based on your personal opnion" ? How you'd classify your post here? lol

Web Analytics