Hi! Aria already sent a very thorough and detailed response (thank you!), but I'd just like to comment on a couple of small details.
On Saturday, December 6, 2014 8:00:24 AM UTC-8, Aria Stewart wrote: > > > > On 6 Dec 2014, at 03:03, Harry Simons <simonsha...@gmail.com> wrote: > > I'm new to Node. It looks very wonderful so far, I must say. > Welcome! Node is indeed a pleasure to play and work with! > > Is there any official documentation on Node Internals, addressing > questions such as the following: > As far as I know, there's no central documentation on how Node works under the hood. However, there are several resources that can help you get the big picture. One of the fundamental components of Node.js is libuv, and you can find an introduction here: http://nikhilm.github.io/uvbook/introduction.html. V8 is another base component, and you can find more information about it here: https://code.google.com/p/v8/. As for Node.js itself, there is no documentation on its implementation that I know of. But since the code is rather small, you should be able to find answers to your questions by reading it. If you have any question, we'll be more than happy to help you answer them. > > 3. How big is the Node's worker thread-pool? Is its size configurable, > or does it automatically scale up/down with load? When this thread pool is > full, say, due to OS limitations or due to configuration parameters > (provided that is even possible), does Node block or throw an exception or > crash when yet another worker thread needs to be engaged? > > Nope: It's fixed-sized, not configurable. If you overflow it, operations > are queued. There's a pending IO queue, and a queue of events to process on > the way back. It's really pretty invisible, just a shim to do asynchronous > IO with synchronous filesystem IO primitives. Thanks, Unix! The thread pool is actually configurable with the "UV_THREADPOOL_SIZE" environment variable. You can find more information about how it's implemented here: https://github.com/libuv/libuv/blob/v1.x/src/threadpool.c#L142. However, I have never changed its value, and I'm not sure this is a recommended solution when the thread pool is overloaded. In addition to filesystem I/O, the thread pool is used for name resolution done with calls to dns.lookup (which uses getaddrinfo on POSIX OSes and GetAddrInfoW on Windows, both synchronous blocking calls). Some node users run into issues when dns.lookup calls take a long time or timeout, because they can prevent other operations (like filesystem operations) to run on the fixed-size thread pool. A good example of such an issue can be found here: https://github.com/joyent/node/issues/2868. It would be tempting in this case to increase the value of the "UV_THREADPOOL_SIZE" environment variable, but I believe a better alternative is first to investigate why dns.lookup calls take a long time or fail, and/or to use dns.resolve. dns.resolve uses asynchronous I/O and thus doesn't run on the thread pool. Other alternatives can be found in the above mentioned issue, and elsewhere. Keep in mind though that dns.resolve doesn't behave like most applications running on the same system since it doesn't use getaddrinfo (or GetAddrInfoW on Windows). It also always does a DNS query over the network, which may or may not be desirable. I hope this helps, and please feel free to ask further questions! Julien -- Job board: http://jobs.nodejs.org/ New group rules: https://gist.github.com/othiym23/9886289#file-moderation-policy-md Old group rules: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines --- You received this message because you are subscribed to the Google Groups "nodejs" group. To unsubscribe from this group and stop receiving emails from it, send an email to nodejs+unsubscr...@googlegroups.com. To post to this group, send email to nodejs@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/nodejs/1c85d4fd-a6a1-435f-a03e-3b6d33f6ef68%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
