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?
Related
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.
I'm a WebAssembly newb just looking to get started, but I have a question I can't seem to find a reasonable answer to. I have an idea of how I would like to design this software, but I don't know if I'm asking the wrong thing of WebAssembly.
Do external JavaScript calls interrupt WebAssembly? Say I'm running a game loop for some visualization, and I want a HTML button bound to JavaScript to change some value within the currently executing WebAssembly context. Is that possible? Would it be more ideal to update values between each frame and only use WebAssembly for per-frame rendering?
The thing is, I really like the targetability of WebAssembly from other languages like C++, as I could never really get into either JavaScript or Typescript, and I'm also looking to build a more performant game-type application. However, since I was planning on making this a web game anyway, I wanted to see if I could use HTML + CSS for my UI elements instead of replicating a UI into WebAssembly, essentially turning it into a terrible canned Java applet.
Yes and no. The short answer is that the browser cannot interrupt long running WebAssembly code.
However, the browser also cannot interrupt long running JS code or deliver any events if you have long running code of any kind. WebAssembly and JS execute on the same execution stack, and in the web model you need to return back the event loop at reasonable intervals. The recommended approach here (for both JS and WebAssembly code) is to break up your game loop and have it run one frame at a time on a callback.
(There are some ways around this, such as using workers to run you long running code or compiler tricks such as binaryen's asynchify to break up your long running code).
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.
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.