- Blog
- About
- Developers
- Sign In
- Public Cloud
- Private Cloud
- Object Storage
- Services
- Partners
- Blog
- About
- Dev Centers
- Sign In
March 11, 2013 - by Isaac Z. Schlueter
Share:
I am pleased to announce a new stable version of Node.
This branch brings significant improvements to many areas, with a focus on API polish, ease of use, and backwards compatibility.
For a very brief overview of the relevant API changes since v0.8, please see the API changes wiki page.
In a previous post, we introduced the "Streams2" API changes. If you haven't reviewed the changes, please go read that now (at least the tl;dr section).
The changes to the stream interface have been a long time in the making. Even from the earliest days of Node, we've all sort of known that this whole "data events come right away" and "pause() is advisory" stuff was unnecessarily awful. In v0.10, we finally bit the bullet and committed to making drastic changes in order to make these things better.
More importantly, all streams in Node-core are built using the same set of easily-extended base classes, so their behavior is much more consistent, and it's easier than ever to create streaming interfaces in your own userland programs.
In fact, the Streams2 API was developed while using it for modules in the npm registry. At the time of this writing, 37 published Node modules already are using the readable-stream library as a dependency. The readable-stream npm package allows you to use the new Stream interface in your legacy v0.8 codebase.
The domain
module has been elevated from "Experimental" to "Unstable" status. It's been given more of a first-class treatment internally, making it easier to handle some of the edge cases that we found using Domains for error handling in v0.8. Specifically, domain error handler no longer relies on process.on('uncaughtException')
being raised, and the C++ code in Node is domain-aware.
If you're not already using Domains to catch errors in your programs, and you've found yourself wishing that you could get better debugging information when errors are thrown (especially in the midst of lots of requests and asynchronous calls), then definitely check it out.
In v0.8 (and before), the process.nextTick()
function scheduled its callback using a spinner on the event loop. This usually caused the callback to be fired before any other I/O. However, it was not guaranteed.
As a result, a lot of programs (including some parts of Node's internals) began using process.nextTick
as a "do later, but before any actual I/O is performed" interface. Since it usually works that way, it seemed fine.
However, under load, it's possible for a server to have a lot of I/O scheduled, to the point where the nextTick
gets preempted for something else. This led to some odd errors and race conditions, which could not be fixed without changing the semantics of nextTick.
So, that's what we did. In v0.10, nextTick
handlers are run right after each call from C++ into JavaScript. That means that, if your JavaScript code calls process.nextTick
, then the callback will fire as soon as the code runs to completion, but before going back to the event loop. The race is over, and all is good.
However, there are programs out in the wild that use recursive calls to process.nextTick
to avoid pre-empting the I/O event loop for long-running jobs. In order to avoid breaking horribly right away, Node will now print a deprecation 1
-getstarted">Get Started
Joyent delivers container-native infrastructure, offering organizations high-performance, yet simple public cloud and private cloud software solutions for today’s demanding real-time web and mobile applications.