Node v0.10.0

Original author: Isaac Z. Schlueter
  • Transfer
I am pleased to announce the release of the new stable version of Node.

Switching to it brings significant improvements in many areas, focused on improving the API, ease of use, and backward compatibility.

For a very brief overview of significant API changes compared to v0.8, please read the API changes wiki page .

Streams2


In the previous blog post, we introduced you to the API changes called Streams2 . If you did not have time to inspect them, please read now at least the then subsection “tl; dr”.

Changes to the thread interface have been prepared for a long time. From the earliest days of Node, we all seemed to know that “ data events begin to arrive immediately” and “calling pause () does not necessarily have an effect” - this is terrible and unnecessary garbage. In version 0.10, we finally worked hard and made major changes to improve thread behavior.

More importantly, now all the threads in the Node core are based on the same set of easily extensible core classes, so their behavior has become much more predictable, and the creation of stream interfaces for your own user programs has been unprecedentedly simplified.

In truth, the Streams2 API was developed as it was used for modules from the npm registry. Currently, 37 published Node modules already use the readable-stream library as one of their dependencies. The readable-stream package for npm allows you to use the new form of the Stream interface in your old v0.8 code.

Error Domains and Error Handling


The status of the domain module has been upgraded from “experimental” to “unstable”. The module has undergone additional first-class processing internally, which will simplify its use in a number of boundary cases observed when using this module to handle errors on top of version v0.8. In particular, domain error handling no longer relies on the process.on ('uncaughtException') handler , and C ++ code in Node is now domain aware.

If you have not previously used domain error catching in your programs, but sometimes would like to receive improved debugging information about thrown errors (especially in the middle of a lot of requests and asynchronous calls), then you should definitely try this module.

Speeding up process.nextTick


In version 0.8 (and earlier) function process.nextTick () to place referred to it a callback function (the callback) in the event queue. This usually triggered a callback before I / O operations began . However, such behavior was not guaranteed.

As a result, in many programs (and in some parts of the Node engine), process.nextTick began to be used as the interface "do it later - but before the real I / O begins ." And since everything usually happened this way, this approach seemed suitable.

However, under load, it was possible for the server to queue so many operationsI / O that the calls passed through nextTick were pushed back. And this led to ridiculous mistakes, caused a race condition - and there was no way to fix it, unless you changed the semantics of nextTick itself.

So that’s exactly what we did. In version 0.10, nextTick handlers fire immediately after each call, from C ++ to JavaScript that happens. And this means that if you have a dzhavaskriptovom code is called process.nextTick, then pass a callback function (callback) will start immediately after execution of the main code - before the moment when to begin processing the event queue. The race is over. All is well.

However, there were also programs that used the recursive call process.nextTick to delay the next step of long-term low-priority tasks until the moment the I / O event queue runs. So that nothing breaks, the Node engine will now print a warning about this situation and ask you to switch to the new setImmediate function for such calls.

Free time response and garbage collection


In languages ​​that rely on garbage collection, it can be far from easy to configure correctly. To avoid unnecessary memory usage, the Node engine previously tried to tell the V8 engine to pick up garbage whenever the event queue was empty.

Unfortunately, it is very difficult to know exactly when such a need arises. “Free time” may not be very free, and if you make a mistake, you can spend a lot of time collecting garbage at the most unexpected moment. In practice, it turned out that disabling the IdleNotification call leads to improved performance, but not to excessive memory usage, because the V8 engine itself knows quite well when to start garbage collection.

So in version 0.10 we picked up this call. (There is such a point of view that we got rid of the bug, which was the very use of this call from the very beginning.) As a result, the response time became more predictable and more stable. As a result, you will not notice differences in benchmarks, however, you will probably find that the response times of your application have become more reliable.

Performance and benchmarks


Translator’s note:   on Habrahabr, as far as I know, there isn’t at all any decent means to change the background in blocks of text written in single-width font. Therefore, I will refrain from translating this subsection with piles of numbers - read it in the original source, who needs it. Its essence is that the performance of the Node engine has increased in a number of its possible applications, but has decreased in some (for example, buffers and UTF-8 strings are sent a bit slower over the network).

Continuous integration


To maintain a high level of code stability (and to hope for earlier catching errors), we use Jenkins, which runs every commit through a set of tests on each of the supported operating systems. You can watch this on the Node Jenkins web portal .

Soon, we will begin daily auto-generation of nightly builds, and eventually the whole process of releasing new versions of Node will be automated.

Although the developers rather scrupulously used tests and benchmarks, with a manual and private approach, some shortcomings could be ignored. General automated product testing will prevent product degradation, such as the one due to whichrelease 0.10 was delayed for several months.

External development


A year ago, we announced that innovations in the Node world will begin to happen in the field of custom modules. Now we have embodied this opinion in its logically completed form, developing new versions of Node internal modules as custom ones. The appearance of readable-stream and tlsnappy modules in this form allowed them to get more user testing, experiments, code donations.

Such a module can be used as a compatibility layer, allowing libraries to resort to new Node features even if it is necessary to support older versions of the Node engine. This development path for Node internal modules is extremely effective. Further development of future developments in the form of user modules will continue.

Growing up


It is often asked with interest whether the Node engine is ready for the present case. I usually reply that it depends on the requirements of your present case, and many highly loaded sites work on Node, and the capabilities of “real” companies using Node in Business have grown more than ever before.

There is not enough space here to give a complete list of companies using Node, and a complete list of support and training options. However, here are a few options that are rapidly expanding and filling the Node for Enterprise space.

Seeking commercial support useful StrongLoop (Noordhuis company Ben and Bert Belder), which released a distribution containing Node v0.10,which they will support on Windows, Macs, Red Hat / Fedora, Debian / Ubuntu, and many cloud platforms. You can download their Node distribution there .

The Node Firm is a worldwide organization of key Node code authors and community members to help businesses successfully use Node. They provide staff training services, consultations, architectural instructions, subscribe to consultations , which helped Skype, Qualcomm and other clients quickly and efficiently learn Node.

Node in its current form is unthinkable without  npm , and npm without its registry of published modules. However, for many businesses, it is problematic to rely on a public registry.Iris npm offers a fully managed private npm registry from Iris Couch , the team responsible for maintaining the public npm registry.

Joyent - the company probably known to you as the custodian of the Node project - provides a high-performance cloud infrastructure, specializing in real-time applications in website building and for mobile devices. Joyent makes extensive use of Node in its engineering solutions and also offers impressive tools for debugging applications after crashes and real-time performance analysis for applications on Node.js. Joyent is also my employer, so I would have to look for a “real” job if they were not Node sponsors :)

What's next: v0.12


The development of Node v0.12 will focus on improving HTTP. The current implementation of HTTP in Node is quite good, and it is quite enough for many interesting applications. However:

  1. The source code is overly confusing. A lot of code is simultaneously used in the server and client, but in such a way that it is unpleasant to even read it, not to mention the correction of errors. There will be a separation of the server and client code, their interfaces will become more clear.
     
  2. The behavior of the socket interrogator is puzzling and unnatural. We will make it configurable and put it in a separate utility. This will make KeepAlive behavior more reasonable, as well as make all of these elements usable in your own programs.

Experiments are underway on the tlsnappy module , which in the future can become an internal implementation of TLS and significantly speed up this business.

1.0


After 0.12, the next major stable release will be 1.0. At that moment, not much will change in the daily work of the project, however, this version will become an important milestone of stability and a decrease in willingness to introduce new features. However, even without that we are strictly striving for backward compatibility, so that in this case the change will not be strong either.

New versions, however, will continue to be released, especially as new versions of those components on which Node is based are released, and bugs will be fixed. They discussed the linking of the Node release cycles to V8 and some interesting possibilities for automating the process of releasing new versions.

Node's goal has always been to achieve, over time, the “final” state of the main program. Of course, this bar is pretty high, and not even that unattainable. But with the widespread adoption of Node and the increasing diversity of Node applications, we are getting closer to the day when significant innovations begin to occur outside of the core Node program.

The stability of the platform provides development on top of it.

And now, the traditional release report:

March 11, 2013, version 0.10.0 (stable)


  • npm: upgrade to version 1.2.14
     
  • core: correctly complement file name in dlopen under Windows (isaacs)
     
  • zlib: handle empty flags (isaacs) correctly
     
  • domains: handle errors thrown in nested error handlers (isaacs)
     
  • buffer: clear high bits when converting to ASCII (Ben Noordhuis)
     
  • win / msi: unlock modification and recovery (Bert Belder)
     
  • win / msi: make some parts of Node selectable (Bert Belder)
     
  • win / msi: persistence of paths to keys in the registry (Bert Belder)
     
  • child_process: support sending dgram socket (Andreas Madsen)
     
  • fs: an EISDIR error will occur on Windows when applying fs.read/write to a directory (isaacs)
     
  • unix: remove strict aliasing warnings, macrofix functions (Ben Noordhuis)
     
  • unix: respect the environment variable UV_THREADPOOL_SIZE (Ben Noordhuis)
     
  • win / tty: fix typo in color attribute enumeration (Bert Belder)
     
  • win / tty: do not touch insert or quick edit mode (Bert Belder)
 

Also popular now: