Node v0.10.0
I am pleased to announce the release of a new stable version of Node.
Going to it brings significant improvements in many areas, focused on improving the API, on ease of use, on backward compatibility.
A very brief overview of significant API changes compared to v0.8, please, on the wiki page about API changes .
')
In the previous blog post, we presented you an API change called “ Streams2 ”. If you did not have time to examine them, please read, now at least the then subsection"tl; dr".
Changes to the thread interface were prepared a long time ago. From the earliest days of Node, we all seemed to knowthat “ data events start coming right away” and “calling pause () does not necessarily have an effect” is a terrible and unnecessary garbage. In version 0.10, we finally strained and made radical changes that improved the behavior of threads.
More importantly, now all the threads in the Node core are based on the same set of easily extensible main classes, so that their behavior is much more predictable, and it’s unbelievably easier to create streaming interfaces for your own user programs.
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 npm readable-stream package allows you to use the new form of the Stream interface in your previous v0.8 code.
The status of the domain module is upgraded from "experimental"to "unstable." The internal module has undergone additional first-class processing, which will simplify its use in a number of boundary cases observed when using this module for error handling on top of version v0.8. In particular, home error handling no longer relies on the process.on ('uncaughtException') handler, and C ++ code in Node is now aware of domains.
If you have not used domain catching errors in your programs before, but sometimes you would like to receive improved debugging information about errors thrown out (especially in the middle of many requests and asynchronous calls), then you should definitely try this module.
In version 0.8 (and even earlier), the process.nextTick ( ) function placed the callback function passed to it in the event queue. This usually led to the launch of a callback beforeI / O operations began . However, this behavior was not guaranteed.
As a result, in a variety of programs (and in some parts of the Node engine), the use ofprocess.nextTick began as an interface "to do this later - but before real I / O begins ." And since everything usually happened this way, this approach seemed to be suitable.
However, under load, it was possible for the server to queue such a large number ofI / O operations that the calls transmitted via nextTick were pushed back. And this led to ridiculous mistakes, caused a race condition - and this could not be fixed, unless the nextTick semantics were changed.
So that's exactly what we did. In version 0.10, the nextTick handlers are triggered immediately after each call,from C ++ to JavaScript of what is happening. And this means that if , then the transferred callback function will start immediately after the main code has been processed - before the moment when the processing of the event queue begins. The race is over. All is well.
However, there were also such programs that used the recursive process.nextTick call to postpone the next step of long-term low-priority tasks until the moment when theI / O event queue was completed . 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.
In languages ​​that rely on garbage collection, it is far from easy to configure correctly. To avoid unnecessary use of memory, the Node engine previously attempted to point the V8 engine to the need for garbage collection whenever the event queue was empty.
Unfortunately, it is very difficult to know exactly when such a need arises. "Free time" may not bevery 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 unnecessary memory usage, because the V8 engine itself knows quite well when it is better to start garbage collection.
So in version 0.10 we picked out this challenge. (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 predictable and stable. You will not notice differences in benchmarks as a result, however, you will probably find that the response times of your application have become more reliable.
To maintain a high level of code stability (and so you can hope for an earlier error trapping), we use Jenkins, which runs each commit through a set of tests on each of the supported operating systems. You can watch thison the Node Jenkins web portal .
Soon, we will begin the daily autogeneration of nightly builds (nightly builds), and over time 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 of the shortcomings could be overlooked. General automated product testing will prevent product deterioration, similar to theone for which release of 0.10 was delayed for several months.
A year ago, we announced that innovations in the Node world would occur in the field of custom modules. Now we have embodied this opinion in its logically complete form, developing new versions of the internal modules of Node as user ones. The appearance of readable-streamand tlsnappy modules in this form allowed them to get more user testing, experimentation, code donations.
Such a module can be used as a compatibility layer, allowing libraries to use the new Node features even if they need to support older versions of the Node engine. This way of developing internal Node modules is extremely effective. Further development of future developments in the form of custom modules will continue.
Often they ask with interest whether the Node engine is ready for the real business. I usually answer that it depends on the requirements of your present business, and many high-load sites work on Node, and the possibilities of “real” companies using Node in Business have increased morethan ever before.
There is not enough space here to provide a complete list of companies using Node, and a full list of support and training options. However, here are a few options that quickly expand and fill the “Node for Enterprise” space.
Those looking for commercial support come in handy with StrongLoop (Ben Noordhuis and Bert Belder’s company), releasing a distro containingNode v0.10, which they will support on Windows, Macs, Red Hat / Fedora, Debian / Ubuntu and many cloud platforms. You can download their distribution Node there .
The Node Firm is the worldwide organization of key Node code authors and community members helping businesses successfully use Node. They provide training services for staff, consulting, architectural instructions, subscribing to consultations , which helped Skype, Qualcomm and other customers to quickly and efficiently learn Node.
Node in its current form is inconceivable without npm , and npm - without its register of published modules. However, for many businesses it is problematic to rely on the public registry. Iris npm offers a fully managed privatenpm registry from Iris Couch , the team responsible for running the public npm registry.
Joyent - a company that is probably known to you as the keeper of the Node project - provides a high-performance cloud infrastructure, specializing in real-time applications in site 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 “real” work if they were notsponsors of Node :)
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. But:
Experiments are underway on the tlsnappy module, which can later become an internal implementation of TLS and significantly speed up this matter.
After 0.12, the next major stable version 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 reduced readiness for the introduction of new features. However, even without that, we are strictly striving for backward compatibility, so that the change will not prove to be strong either.
New versions, however, will continue to be released, especially as new versions of the components on which the Node is based are released, and bugs will be fixed. They discussed the linking of the Node release cycles to the V8 and some interesting possibilities to automate the release process of the new versions.
The goal of Node has always been to achieve the “final” state of the main program over time. Of course, this strap is fairly sublime, and not even out of reach. But with the widespread introduction of Node and the growing diversity of Node applications, we are getting closer to the day when significant innovations will occur outside the main Node program.
Stability of the platform provides development on top of it.
And now - the traditional release report:
Going to it brings significant improvements in many areas, focused on improving the API, on ease of use, on backward compatibility.
A very brief overview of significant API changes compared to v0.8, please, on the wiki page about API changes .
')
Streams2
In the previous blog post, we presented you an API change called “ Streams2 ”. If you did not have time to examine them, please read, now at least the then subsection
Changes to the thread interface were prepared a long time ago. From the earliest days of Node, we all seemed to know
More importantly, now all the threads in the Node core are based on the same set of easily extensible main classes, so that their behavior is much more predictable, and it’s unbelievably easier to create streaming interfaces for your own user programs.
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 npm readable-stream package allows you to use the new form of the Stream interface in your previous v0.8 code.
Error domains and error handling
The status of the domain module is upgraded from "experimental"
If you have not used domain catching errors in your programs before, but sometimes you would like to receive improved debugging information about errors thrown out (especially in the middle of many requests and asynchronous calls), then you should definitely try this module.
Acceleration process.nextTick
In version 0.8 (and even earlier), the process.nextTick ( ) function placed the callback function passed to it in the event queue. This usually led to the launch of a callback before
As a result, in a variety of programs (and in some parts of the Node engine), the use of
However, under load, it was possible for the server to queue such a large number of
So that's exactly what we did. In version 0.10, the nextTick handlers are triggered immediately after each call,
process.nextTickHowever, there were also such programs that used the recursive process.nextTick call to postpone the next step of long-term low-priority tasks until the moment when the
Response time and garbage collection in free time
In languages ​​that rely on garbage collection, it is far from easy to configure correctly. To avoid unnecessary use of memory, the Node engine previously attempted to point the V8 engine to the need for garbage collection whenever the event queue was empty.
Unfortunately, it is very difficult to know exactly when such a need arises. "Free time" may not be
So in version 0.10 we picked out this challenge. (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 predictable and stable. You will not notice differences in benchmarks as a result, 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 are notolerable means at all for changing the background in blocks of text written in a 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 in a number of its possible applications, but in some it decreased (for example, buffersand UTF-8 strings are sent a little slower through the network).
Continuous integration
To maintain a high level of code stability (and so you can hope for an earlier error trapping), we use Jenkins, which runs each commit through a set of tests on each of the supported operating systems. You can watch this
Soon, we will begin the daily autogeneration of nightly builds (nightly builds), and over time 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 of the shortcomings could be overlooked. General automated product testing will prevent product deterioration, similar to the
External development
A year ago, we announced that innovations in the Node world would occur in the field of custom modules. Now we have embodied this opinion in its logically complete form, developing new versions of the internal modules of Node as user ones. The appearance of readable-stream
Such a module can be used as a compatibility layer, allowing libraries to use the new Node features even if they need to support older versions of the Node engine. This way of developing internal Node modules is extremely effective. Further development of future developments in the form of custom modules will continue.
Growing up
Often they ask with interest whether the Node engine is ready for the real business. I usually answer that it depends on the requirements of your present business, and many high-load sites work on Node, and the possibilities of “real” companies using Node in Business have increased more
There is not enough space here to provide a complete list of companies using Node, and a full list of support and training options. However, here are a few options that quickly expand and fill the “Node for Enterprise” space.
Those looking for commercial support come in handy with StrongLoop (Ben Noordhuis and Bert Belder’s company), releasing a distro containing
The Node Firm is the worldwide organization of key Node code authors and community members helping businesses successfully use Node. They provide training services for staff, consulting, architectural instructions, subscribing to consultations , which helped Skype, Qualcomm and other customers to quickly and efficiently learn Node.
Node in its current form is inconceivable without npm , and npm - without its register of published modules. However, for many businesses it is problematic to rely on the public registry. Iris npm offers a fully managed private
Joyent - a company that is probably known to you as the keeper of the Node project - provides a high-performance cloud infrastructure, specializing in real-time applications in site 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 “real” work if they were not
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. But:
- The source code is excessively confused. A lot of code is simultaneously used in the server and the 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 server and client code, their interfaces will become more clear.
- The behavior of the socket poll maker is puzzling and unnatural. We will make it configurable and render it into a separate utility. That will make KeepAlive more reasonable, and also make all these elements suitable for use in your own programs.
Experiments are underway on the tlsnappy module, which can later become an internal implementation of TLS and significantly speed up this matter.
1.0
After 0.12, the next major stable version 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 reduced readiness for the introduction of new features. However, even without that, we are strictly striving for backward compatibility, so that the change will not prove to be strong either.
New versions, however, will continue to be released, especially as new versions of the components on which the Node is based are released, and bugs will be fixed. They discussed the linking of the Node release cycles to the V8 and some interesting possibilities to automate the release process of the new versions.
The goal of Node has always been to achieve the “final” state of the main program over time. Of course, this strap is fairly sublime, and not even out of reach. But with the widespread introduction of Node and the growing diversity of Node applications, we are getting closer to the day when significant innovations will occur outside the main Node program.
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 the file name in dlopen under Windows (isaacs)
- zlib: correctly handle havoc flags (isaacs)
- domains: handle errors thrown in nested error handlers (isaacs)
- buffer: clear high bits when converting to ASCII (Ben Noordhuis)
- win / msi: unlock modification and restoration (Bert Belder)
- win / msi: make some parts of Node selectable (Bert Belder)
- win / msi: constancy of paths to keys in the registry (Bert Belder)
- child_process: support dgram socket send (Andreas Madsen)
- fs: a Windows EISDIR error will occur when applying fs.read/write to a directory (isaacs)
- unix: eliminate strict pseudonymity warnings, macro-define functions (Ben Noordhuis)
- unix: respect the environment variable UV_THREADPOOL_SIZE (Ben Noordhuis)
- win / tty: correct typo in the color attribute enumeration (Bert Belder)
- win / tty: do not touch the insert mode or quick edit (Bert Belder)
Source: https://habr.com/ru/post/172363/
All Articles