I have learned that, JavaScript is always single-threaded. If you're executing a JavaScript block of code on a page then no other JavaScript on that page will currently be executed.
If this is the case then how Javascript manage Ajax call? If a single thread is busy and currently executing other Javascript on that page then how thread manage when call return(success or otherwise) from ajax? Is Javascript internally uses more than a thread to handle call return?
The javascript engine itself is single threaded, but javascript executes in a hosting environment that includes more than just the js engine. A hosting environment would be something such as a browser, a server, etc.
Within the hosting environment is something called an event loop. This event loop manages when certain parts of a js script should run. So when you write something such as:
setTimeout(() => console.log('tick'), 1000)
the callback function gets put on the event loop (not quite, but close enough for explanation purposes) and once the current js execution thread is empty the event loop will check if there is anything in the queue and if there is it will push it onto the main js execution thread.
So in summary, the js engine itself is single threaded but there is a lot more that goes into a full js hosting environment that makes it work.
JavaScript is single-threaded with respect to the code that is executed within one context. So in a JavaScrip Engine code of the same context cannot run in parallel. You can have multiple contexts running in parallel (like WebWorkers), but different contexts cannot share objects (or only in a clearly define and limited way).
The IO is implemented with an event-based approach, which means, that out of the perspective of the JavaScript side, data is pushed to or pulled from a buffer. How that buffer is filled/emptied is not in the JavaScript Land anymore, and at that point, the engine could use threads, or continue to use an event-based approach like libuv (which is used by V8 the js engine of chrome and nodejs) provides. libuv or the system then itself would do something with the data, which again could either be done with threads or event-based.
So, in theory, the IO could be done completely without threads.
JavaScript is actually single threaded because every JavaScript code will run in a single thread (that's not true anymore in the modern web because Web workers allow JavaScript code to run in separate threads, though). That means there is a single callback queue, and the callbacks run when the main thread is not busy, and thus can potentially be delayed. Also, note that the UI (web page) is blocked while JavaScript runs, preventing the user from doing anything.
All of the browser's internal mechanisms such as XMLHttpRequest are not JavaScript, only the API is (send(), open(), onreadystatechange, etc.), so it's up to the browser's editor to make use of other threads for these internal mechanisms, as long as the API complies with the W3C specification.
Related
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.
I'm learning about the event loop from this blog but seems like the author goes into general computer program concepts I'm not too familiar with -
This includes HTTP requests, database operations and disk reads and
writes; the single thread of execution asks the runtime to perform an
operation, providing a callback function and then moves on to do
something else.
Is the single thread of execution part of Javascript that is used to talk to another part of Javascript, which is the runtime? Or is the execution part of the browser? I'm probably completely wrong, but my understanding so far is that when you go to a webpage, the browser gets some javascript, and has only a thread to execute that javascript, so it uses that thread to send a message to the runtime, which is part of the cpu to actually run that script and that's results in the script working on your webpage?
I've been doing a lot of research into the core of Node.js lately, and I have some questions about the inner workings of the Node platform. As I understand it, Node.js works like this:
Node has an API, written in Javascript, that allows the programmer to interact with things like the filesystem and network. However, all of that functionality is actually done by C/C++ code, also a part of Node. Here is where things get a little fuzzy. So it's the Chrome V8 engine's job to essentially "compile"(interpret?) javascript down into machine code. V8 is written in C++, and the Javascript language itself is specified by ECMA, so things such as keywords and features of the language are defined by them. This leads me to my first few questions:
How is the Node Standard Library able to interact with the Node Bindings, since the Node Bindings are written in C++?
How does the Chrome V8 engine interpret Javascript in the context of Node? I know it uses a technique called JIT, which was mentioned in a similar question: (https://softwareengineering.stackexchange.com/questions/291230/how-does-chrome-v8-work-and-why-was-javascript-not-jit-compiled-in-the-first-pl)
But this doesn't explain how Javascript is interpreted in the context of Node. Is the Chrome V8 engine that ships with Node the exact same engine that runs on the Chrome browser, or has it been modified to work with Node?
That brings me to my next question. So Node features event-driven, non-blocking IO. It accomplishes this via the Event Loop, which, although it is often referred to as the "Node Event Loop", is actually a part of the libuv library, a C++ library designed to provide asynchronous IO. At a high level, the event loop is essentially accessed via Callbacks, which is a native Javascript feature and one of the reasons Javascript was chosen as the language for the Node project. Below is an illustration of the how the event loop works:
This can also be demonstrated live by this neat little site: http://latentflip.com/loupe/
Let's say our Node application needs to make a call to an external API. So we write this:
request(..., function eyeOfTheTiger() {
console.log("Rising up to the challenge of our rival");
});
Our call to request gets pushed onto the call stack, and our callback is passed somewhere, where it is kept until the request operation finishes. When it does, the callback is passed onto the callback queue. Every time the call stack is cleared, the event loop pushes the item at the top of the callback queue onto the call stack, where it is executed. This event loop is run on a single thread. Where problems arise is when someone writes 'blocking' code, or code that never leaves the call stack and effectively ties up the thread. If there is always code executing on the call stack, than the event loop will never push items from the callback queue onto the call stack and they will never get executed, essentially freezing the application. This leads me to my next question:
If the Javascript is interpreted by the Chrome V8 engine, than what "controls" the pushing of code onto the callback queue? How is Javascript code handled by the libuv event loop?
I've found this image as a demonstration of the process:
This is where I'm uncertain about how exactly Chrome V8 engine and libuv interact. I'm inclined to believe that the Node Bindings facilitate this interaction, but I'm not quite sure how. In the image above, it appears as though the NodeJS bindings are only interacting with machine code that has been compiled down from Javascript by V8. If so, than I am confused as to how the V8 engine interprets the Javascript in such a way that the Node Bindings can differentiate between the callback and the actual code to immediately execute.
I know this is a very deep and complicated series of questions, but I believe this will help to clear up a lot of confusion for people trying to understand Node.js, and also help programmers to understand the advantages and disadvantages of event-driven, non-blocking IO at a more fundamental level.
Status Update: Just watched a fantastic talk from a Sencha conference(Link here). So in this talk, the presenter mentions the V8 embed guide(Link here), and talks about how C++ functions can be exposed to Javascript and vice versa. Essentially how it works is that C++ functions can be exposed to V8 and also specify how it wants those objects to be exposed to Javascript, and the V8 interpreter will be able to recognize your embedded C++ functions and execute them if it finds Javascript that matches what you specified. For example, you can expose variables and functions to V8 that are actually written in C++. This is essentially what Node.js does; it is able to add functions like require into Javascript that actually execute C++ code when they are called. This clears up question number 1 a little, but it doesn't exactly show how the Node standard library works in conjunction with V8. It is still also unclear about how libuv is interacting with any of this.
Basically what you are looking for is V8 Templates. It exposes all your C++ code as JavaScript functions that you can call from within the V8 Virtual Machine. You can associate C++ callbacks when functions are invoked or when specific object properties are accessed (Read Accessors and Interceptors).
I found a very good article which explains all of this - How does NodeJS work?. It also explains how libuv works in conjunction with Node to achieve asynchronicity.
Hope this helps!
It says in a lot of website that JavaScript is single-threaded. When they say this, do they mean the JavaScript runtime?
I might be misunderstanding something but isn't JavaScript just a programming language and the programs you create with it should be the ones labeled as single-threaded? But maybe I'm not understanding something so can someone please explain what I am don't getting?
JavaScript, the language, is nearly silent on the topic of threading. Whether it's single- or multi-threaded is a matter of the environment in which it runs. There are single-threaded JavaScript environments, and multi-threaded JavaScript environments. The only real requirement the specification makes is that a thread have a job queue and that once a job (a unit of code to run, like a call to an event handler) is started, it runs to completion on the thread before another job from that queue is started. That is, JavaScript has run-to-completion semantics.
JavaScript on browsers isn't single-threaded and hasn't been for years. There is one main thread (the thread the UI is handled on), and any number of web worker threads. The web workers don't have direct access to the UI, they send messaegs to the UI thread, and it does the UI updates. The threads don't directly share data, they share data explicitly via messaging. This separation makes programming multi-threaded code dramatically simpler and less error-prone than if multiple threads had access to the UI and the same common data area. (Writing correct multi-threaded code where any thread can access anything at any time is hard.)
Outside the browser, JavaScript in NodeJS is run on a single thread. There was a fork of Node to add multi-threading, but I don't think it ever went anywhere.
JavaScript on the JVM (Rhino, Nashorn) has always been multi-threaded, supported by the threading facilities of the JVM.
While TJC's answer is of course correct, I don't think it addresses the issue of what people actually mean when they say that "JavaScript is single-threaded". What they're actually summarising (inaccurately) is that the run-time must behave as if has a single thread of execution, which cannot be pre-empted, and which must run to completion. The actual runtime can do anything it likes as long as the end result behaves in this way.
This means that while a JavaScript program may appear to be massively parallel with lot of threads interacting with each other, it's actually nothing of the sort. A kernel controls everything using the queue, event loop, and run-to-completion semantics (briefly) described here.
This is exactly the same problem that Hardware Description Languages (VHDL, Verilog, SystemC (though not actually a language), and so on) face. They give the illusion of massive parallelism by having a runtime kernel cycle between 'processes' which are not pre-emptible, and which must run until defined suspend points. The point of this is to ensure that models are executed in a determinate, repeatable fashion.
The difference between the HDLs and JS is that this is very well defined and fundamental for HDLs, while it's glossed over for JS. This is an extract from the SystemC LRM, which covers it briefly - it's much better defined in the VHDL LRM, for example.
Since process instances execute without interruption, only a single
process instance can be running at any one time, and no other process
instance can execute until the currently executing process instance
has yielded control to the kernel. A process shall not pre-empt or
interrupt the execution of another process. This is known as
co-routine semantics or co-operative multitasking.
I am learning Node.js and I have read that Node.js is single threaded and non-blocking.
I have a good background in JavaScript and I do understand the callbacks, but what I don't really understand is how Node.js can be single threaded and run code in the background. Isn't that contradictory?
Because if Node.js is single threaded it can still only perform one task at the time. So if it runs something in the background it has to stop the current task to process something in the background, right?
How does that work practically?
What "in the background" really means in terms of NodeJS is that things get put on a todo list for later. Whenever Node is done with what it's doing it picks from the top of the todo list. This is why doing anything that actually IS blocking can wreck your day. Everything that's happening "in the background" (actually just waiting on the todo list) gets stopped until the blocking task is complete.
Lucas explained it well, but I would like to add, this is possible to add "nodes" via some cluster libraries if you want to take advantage of your processors.
https://www.npmjs.com/package/cluster
https://www.npmjs.com/package/pm2
A tutorial to do a cluster: http://blog.carbonfive.com/2014/02/28/taking-advantage-of-multi-processor-environments-in-node-js/
Some hosters will give your the 'scalability' options, like Heroku
Anyway, when you use MongoDB with NodeJS (via Mongoose for example), it creates multiples connections.
NOTE: The advantage to be monothreaded is to handle millions users. With a legacy multithreaded server (apache), you create a thread for EACH user, then you need really BIG servers to handle thousands people.
While the JavaScript engine is monothreaded, there are multiple threads "in the background" that deal with all the non-blocking I/O work.
Specifically, libuv has a pool of worker threads waiting on OS events, I/O signals, running C++ code, etc. Size of this pool is determined by the UV_THREADPOOL_SIZE environment variable.
No JavaScript code ever runs "in the background". JavaScript functions (i.e. callbacks) are scheduled to run later on the main event loop, either by other JS functions or directly by the libuv workers. If the loop is blocked, then everything scheduled has to wait for it.
In fact, Node.js is not exactly monothreaded. Node.js use one "main thread", which is the thread where you script is executed. This main thread must never be blocked. So long-running operations are executed in separate threads. For example, Node.js use libuv library which maintains a pool of threads used to perform I/O.