This question already has answers here:
How to create threads in nodejs
(12 answers)
Closed 6 years ago.
Node.js multithreading.
Is it possible to use multithreading in Node.js? if yes.
What are the advantages and disadvantages of using multithreading in Node.js? Which are those modules that can be achieve multithreading in Node.js? I am a newbie to Node.js, I read from many blogs saying that Node.js is single threaded.
I know the java multithreading but I need to know whether it is possible in Node.js or not.
Yes and No. Let's start from the beginning. Why is NodeJs single-threaded, is explained here Why is Node.js single threaded?
While Node.js itself is multithreaded -- I/O and other such operations run from a thread pool -- JavaScript code executed by Node.js runs, for all practical purposes, in a single thread. This isn't a limitation of Node.js itself, but of the V8 JavaScript engine and of JavaScript implementations generally.
Node.js includes a native mechanism for clustering multiple Node.js processes, where each process runs on a separate core. But that clustering mechanism doesn't include any native routing logic or shared state between workers.
Generally and more clearly the statement is that, each node.js process is single threaded .if you want multiple threads, you have to have multiple processes as well.
For instance,you can use child process for this, which is described here http://nodejs.org/api/child_process.html . And just for your info, check out also this article, is very instructive and well written, and possibly will help you, if you want to work with child_processes -- https://blog.scottfrees.com/automating-a-c-program-from-a-node-js-web-app
Despite of all of the above, you can achieve a kind of multi-threading with C++ and native nodejs C++ development.
First of all check out these answers, probably they will help you,
How to create threads in nodejs
Node.js C++ addon: Multiple callbacks from different thread
Node.js C++ Addon: Threading
https://bravenewmethod.com/2011/03/30/callbacks-from-threaded-node-js-c-extension/
Of course you can find and leverage a lot of node plugins which are giving "multi"-threading capability: https://www.npmjs.com/search?q=thread
In addition, you can check JXCore https://github.com/jxcore/jxcore
JXCore is fork of Node.js and allows Node.js apps to run on multiple threads housed within the same process. So most probably JXCore is a solution for you.
"What are the advantages and disadvantages of using multi-threading in Node.js ?"
It depends of what you want to do. There are no disadvantages if you leverage and use Node.js sources correctly, and your "multi" - threaded plugins or processes or whatever, do not "hack" or misuse anything from the core of V8 or Node.js !
As in every answer, the correct answer is "use the right tools for the job".
Of course, since node is by design single-threaded, you can have better approaches for multithreading.
A technique that a lot of people use, is to make their multi-threaded application in C++, Java, Python e.t.c and then, they run it via automation and Node.js child_process (third-party application runs asynchronously with automation, you have better performance (e.g C++ app), and you can send input and get output in and from your Node.js application).
Disadvantages multi-threading Node.js
Check this: https://softwareengineering.stackexchange.com/questions/315454/what-are-the-drawbacks-of-making-a-multi-threaded-javascript-runtime-implementat
Keep in mind that if you want to create a pure multithreaded environment in Node.js by modifying it, I suppose that would be difficult, risky due to the complexity, moreover you have to be, always up to date with each new V8 or Node release that will probably affect this.
No, you can't use threads in node.js. It uses asynchronous model of code execution. Behind the asynchronous model, the node itself uses threads. But as far as I know, they can't be accessed in the app without additional libraries.
With the asynchronous model you don't actually need threads. Here is a simple example. Normally, in multi-threaded environments, you would run networks requests in each thread to not block the execution of code in main thread. With async model, those requests do not block the main thread and are still executed in other threads, only this is hidden from you to make development process straightforward.
Also check this comment by bazza.
Related
So, maybe this question is too noob and novice to be asked but I still have no clue why LIBUV got a place in Node JS Architecture? So here is my understanding of NodeJs architecture.
Node Js is built over V8
V8 is capable of running code written with EcmaScript standards.
V8 is written in C++.
So if you want to give any new functionality we can embed V8 in our C++ project and attach new code with new Embedded V8 in C++.
Now here is the doubt,
Since V8 supports EcmaScript Javascript that means it has the capability to run callbacks written with the standards of EcmaScript.
So we can add code for File System Access, HTTP server & DB access in C++ since there are libraries (header files) that gives that functionality since Java is written in C++ (correct me if I am wrong) and Java has the capability to do the same.
Now if we can add this functionality in C++ where does the place for Libuv come into the picture of NodeJs architecture.
Thanks in advance and
Happy Coding :)
Check the docs below -
https://nodejs.org/en/docs/meta/topics/dependencies/#libuv
Another important dependency is libuv, a C library that is used to
abstract non-blocking I/O operations to a consistent interface across
all supported platforms. It provides mechanisms to handle file system,
DNS, network, child processes, pipes, signal handling, polling and
streaming. It also includes a thread pool for offloading work for some
things that can't be done asynchronously at the operating system
level.
So to sum it up, V8 provides the functionalities related to running JS files, but to use system resources like Network, Files, etc., libuv is used. Also it provides a threading model for accessing the resources mentioned.
The libuv module has a responsibility that is relevant for some particular functions in the standard library. for SOME standard library function calls, the node C++ side and libuv decide to do expensive calculations outside of the event loop entirely.They make something called a thread pool that thread pool is a series of four threads that can be used for running computationally intensive tasks such as hashing functions.
By default libuv creates four threads in this thread pool. So that means that in addition to that thread used for the event loop there are four other threads that can be used to offload expensive calculations that need to occur inside of our application. Many of the functions include in the node standard library will automatically make use of this thread pool.
Now the presence of this thread pool is very significant. Well clearly Node.js is not truly single threaded
Libuv also gives node access to the operating system’s underlying file system such as networking. So just as the node standard library has some functions that make use of libuv thread pool it also has some functions that make use of code that is built into the underlying operating system through libuv.
Simple Http request
const https=require(“https”)
const start=Date.now()
https.request(“https://www.google.com”,res=>{
res.on(“data”,()=>{} )
res.on(“end”,()=>{console.log(Date.now()-start) }) }).end()
So in this case libuv sees that we are attempting to make an HTTP request. Neither libuv nor node has any code to handle all of this low level operations that are involved with a network request. Instead libuv delegates the request making to the underlying operating system. So it's actually our operating system that does the real HTTP request Libuv is used to issue the request and then it just waits on the operating system to emit a signal that some response has come back to the request. So because Libuv is delegating the work done to the operating system the operating system itself decides whether to make a new threat or not. Or just generally how to handle the entire process of making the request.
If anyone stumbles upon this and since it lacks a good answer to the OP's question, I will try to take on this.
TLDR;
Javascript language is not asynchronous
Javascript language is not multi-threaded
Callbacks themselves are not asynchronous, they are just mean to piggyback your code to an asynchronous operation.
Let's go over your doubts one by one.
1. Since V8 supports EcmaScript Javascript that means it has the capability to run callbacks written with the standards of EcmaScript.
Callbacks don't mean that the operation is asynchronous. A callback has got nothing to do with asynchronous execution. Callback is just a way to piggyback your function so that it executes after 'something asynchronous'.
// example of synchronous callback
function main(cb) {
console.log('main code of the function');
cb(); // callback invocation here
}
main(function () {
console.log('in callback');
});
Now an example of asynchronous callback
function getDataFromNetwork(url, cb) {
ajaxCall(url).then(cb);
}
getDataFromNetwork('http://some-endpoint', function (data) {
console.log(data);
});
This is an asynchronous call with a callback. Here getDataFromNetwork function is asynchronous not the callback. The point is that callbacks are just a mechanism of running a code after something. In an asynchronous operation, this becomes a necessity. How else we are going to do that? right?
No!
Nowadays we have async-await where you can run a code after the asynchronous function completes without using callbacks.
So you get that? Callbacks are not asynchronous. And that's not the point of having libuv.
2. So we can add code for File System Access, Http server & DB access in C++ since there are libraries (header files) that gives that functionality since Java is written in C++ (correct me if I am wrong) and Java has the capability to do the same.
Yes we can add lots of code for File System Access, Http server. But Why? We do already have a lot of libraries to do that. And yes its already written in C thats how NodeJS executes them.
Java already has that?
Right, but thats also a part of JVM rather than the core Java language, just like libuv is part of NodeJS runtime rather than the core Javascript language. In this regard both Java and NodeJS are similar. Its just that Java has its own C++ layer and NodeJS borrows libuv for that. BTW libuv was primarily built for NodeJS
3. Now if we can add these functionality in C++ where does the place for Libuv come in to the picture of NodeJs architecture.
I answered how these functionalities are already in C++, now lets see where libuv fits in this picture of the whole architecture.
Lets take an ajax/network call for example. Who do you think executes this?
NodeJS? No, It just gives instruction to its C++ API (Node API).
then is it Node API? No, It just gives instruction to the libuv
then is it libuv? Yes, it is
Same goes for timers, file access, child processes etc.
Also think when a lot of network calls, file access are fired within a NodeJS program, on what process it runs? who schedules them? who notify about the results and failure.
This is a lot to do. Java has its own thread pool to do that. Java has its own schedular to schedule the threads. and since Java provides threads to end user(programmers) as well. It makes sense to implement all that stuff using Java threads.
But NodeJS is single-threaded. Why it should have threads to execute I/O operations when it can borrow it from another library without making them a part of Javascript? After all, we aren't going to provide threads to the programmer so why bother?
Also Historically, Javascript was only meant to run in browsers. The only asynchronous operation browsers had access to were network requests, no file access, no DB. So we did not have a lot of bedrock already to build upon.
I am in the middle of building data modeling in MongoDB which will work with Nodejs. I am keen to understand the basic level working of how threads handle flow of execution in Javascript. Basically i want to understand if their is any difference in terms of execution of threads of Javascript & Nodejs. The javascript is single threaded and the Nodejs built upon v8 javascript is also single threaded! What could be the breakthrough difference in terms of execution between these two.
The terminology in your question is a bit messed up and thus it appears your question is a bit misdirected. Trying to compare "Javascript" to node.js does not really make sense. node.js runs Javascript code just fine. You don't really compare the two. I'm going to assume that what you meant to compare is "Javascript in the Chrome browser" vs. "Javascript in node.js".
The main thread of Javascript in both Chrome (or any other browser) and node.js is single threaded. They behave the same in that regard and, in fact, node.js and Chrome use the exact same V8 Javascript execution engine. All coordination with the outside world or with other native code is via the event queue.
Modern browsers do have webWorkers which allow additional threads of Javascript, but those threads are very restricted in what they can do (for example, they cannot access the DOM) and in how they can communicate with the main Javascript thread (all communication is via messaging - direct function calls or shared variables are not allowed). webWorkers are almost as isolated as separate processes would be in node.js.
Both Chrome and node.js have native code libraries that use native threads to implement their work, but when they interface with the user's Javascript code, they all go through the event queue and that's how they connect with the single threaded Javascript code.
Based on my understanding, only I/O in NodeJS is non-blocking. If we do, for example, lots of heavy math operations, other users cannot access to the server until it's done.
I was wondering if there is a non-blocking way to do heavy computation in NodeJS? Just curious.
If you have long-running calculations that you want to do with Node, then you will need to start up a separate process to handle those calculations. Generally this would be done by creating some number of separate worker processes and passing the calculations off to them. By doing this, you keep the main Node event loop unblocked.
On the implementation side of things, you have two main options.
The first being that you manually spin off child processes using Node's child-process API functions. This one is nice because your calculations wouldn't even have to be javascript. The child process running the calculations could even be C or something.
Alternatively, the Web Worker specification, has several implementations available through NPM if you search for 'worker'. I can't speak to how well these work since I haven't used any, but they are probably the way to go.
Update
I'd go with option one now. The current child process APIs support sending messages and objects between processes easily in a worker-like way, so there is little reason to use a separate worker module.
You can use Hook.io to run a separate node process for your heavy computation and communicate between the two. Hook.io is particularly useful because it has auto-healing meshes meaning that if one of your hooks (processes) crashes it can be restarted automatically.
Use multiple NodeJS instances and communicate over sockets.
Use multiple node instances and communicate over node-zeromq, HTTP, plain TCP sockets, IPC (e.g. unix domain sockets), JSON-RPC or other means. Or use the web workers API as suggested above.
The multiple instances approach has its advantages and disadvantages. Disadvantages are that there is a burden of starting those instances and implementing own exchange protocols. Advantages are that scaling to many computers (as opposed to many cores/processors within a single computer) is possible.
I think this is way to late, but this is an awesome feature of nodejs you've to know about.
The only way abot multithreading is by spawning new processes, right so far.
But nodejs has an implemented message feature between spawned node-forks.
http://nodejs.org/docs/latest/api/child_processes.html#child_process.fork
Great work from the devs, you can pass objects etc. as message to your childs and backwards
You can use node cluster module.
https://nodejs.org/api/cluster.html
I would use JXCore - it's a polished nodejs based engine which runs your code but has several options including the multi threading you are searching for. Running this in production is a charm!
Project's source: https://github.com/jxcore/jxcore
Features include:
Support for core Node.JS features
Embeddable Interface
Publish to Mobile Platforms (Android, iOS ..)
Supports Multiple JavaScript Engines
Multi-threading Capabilities
Process Configuration & Monitor
In-memory File System
Application Packaging
Support for the latest JavaScript features (ES6, ASM.JS ...)
Support for Universal Windows Platform (uwp) api
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
How to decide when to use Node.js?
Sorry if I'm a bit ambiguous, but I'm trying to understand the real advantages of using Node.js instead of other server-side language.
I'm a JavaScript enthusiast, so I'm probably going to play with Node.js, but I want to know if I should use it in my projects.
It's evented asynchronous non-blocking I/O build ontop of V8.
So we have all the performance gain of V8 which is the Google JavaScript interpreter. Since the JavaScript performance race hasn't ended yet, you can expect Google to constantly update performance on V8 (for free).
We have non-blocking I/O which is simply the correct way to do I/O. This is based on an event loop and using asynchronous callbacks for your I/O.
It gives you useful tools like creating a HTTP server, creating a TCP server, handling file I/O.
It's a low level highly performant platform for doing any kind of I/O without having to write the entire thing in C from scratch. And it scales very well due to the non-blocking I/O.
So you want to use Node.js if you want to write highly scaling and efficient applications using non-blocking I/O whilst still having a high level scripting language available. If needed, you can hand optimise parts of your code by writing extensions in C.
There are plenty of OS libraries for Node.js that will give you abstractions, like Express.js and now.
You don't want to use Node.js if you want (slow) high level abstractions to do everything for you. You don't want to use Node.js if you want RAD. You don't want to use Node.js if you can't afford to trust a young platform, either due to having to write large pieces of code yourself to do things that are build into other frameworks or because you can't use Node.js, because the API isn't stable yet or it's a sub 1.0 release.
The two most oft-quoted advantages are:
JavaScript is both server-side and client-side. There are fewer things to learn, less context switching, and the ability to reuse code across the two sides.
Uses non-blocking I/O, and Chrome's V8 engine, to provide fast, highly scalable servers.
For me though, the most interesting part is the amount of activity happening in this area. There are a lot of very interesting ideas under development for node - be sure to check out the list of Node.js modules.
When you're (or even if you are not) a JavaScript enthusiast you can/should use Node.js for a number of reasons:
It's a low-level, lightweight and standalone framework which brings power of JavaScript to the server-side environment.
If you like more higher level abstraction then there is a large number of modules and the npm package manager where you can find wide range of ready-to-use applications.
Fast/unencumbered development process - for example, you don't need tons of additional tools in order to start writing serious stuff.
Big open source based community full of enthusiasts and very talented people.
Made for creating real-time web oriented applications - that's where the (near) future is.
Personally, I'd most likely use Node.js when:
I want to write a server that doesn't use the HTTP protocol.
I'm prototyping a server implementation.
I'm writing a server that isn't expecting a ton of traffic (although I've never profiled a Node.js implementation next to, say, a matching C++ implementation).
I want to get active in the community (which is apparently growing quite rapidly).
I am a web developer writing a lot of code in jquery.
I am trying to learn YUI3 and I notice the 'node' module there. I also heard about something called Node.js. Are the YUI3 node module and Node.js related ?
The official Node.js website does not seems to have much info.
What exactly is Node.js?
It is server-side does that mean we can used Node.js instead say PHP ?
What kind of applications are being developed using Node.js?
Is it worth for a web developer to invest time learning this ?
Node.js is actually a JavaScript framework for asynchronous servers. It runs server-side, rather than client-side like the YUI3 widgets library, and, chances are, if you don't need to roll your own high-performance evented sockets/asynchronous HTTP/etc. server and are just looking to write run-of-the-mill websites, then there is no need to learn Node.js.
(that said, Node.js is still pretty cool.)
Node.js is an evented I/O JavaScript server platform. It makes it relatively easy to create things like sockets and quickly handle many concurrent connections.
Node is similar in design to and influenced by systems like Ruby's Event Machine or Python's Twisted. Node takes the event model a bit further—it presents the event loop as a language construct instead of as a library. In other systems there is always a blocking call to start the event-loop. Typically one defines behavior through callbacks at the beginning of a script and at the end starts a server through a blocking call like EventMachine::run(). In Node there is no such start-the-event-loop call. Node simply enters the event loop after executing the input script. Node exits the event loop when there are no more callbacks to perform. This behavior is like browser javascript—the event loop is hidden from the user.
About Node.js
the biggest connection between YUI3 and node.js is yeti
a command-line tool for launching JavaScript unit tests in a browser and reporting the results without leaving your terminal.