spacer

Announcing Node v0.10.0

Thank You

Thank you for contacting us. We will get back to you shortly.

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.

Streams2

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.

Domains and Error Handling

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.

Faster process.nextTick

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.

More From Announcements

  • Predicteria 2015
  • 2014 in Review: Docker Rising
  • Making Joyent the Best Place to Run Docker
  • How Joyent and Docker are Working Together
  • SmartDataCenter and Manta are now open source
gipoco.com is neither affiliated with the authors of this page nor responsible for its contents. This is a safe-cache copy of the original web site.