I am no beginner in javascript. I am actually working on this for past 3-4 months but today I read this statement about "What is JavaScript?"
JavaScript is single-threaded, non-blocking, asynchronous, concurrent language.
and I was lost. If JavaScript is single-threaded, how can it be concurrent and how can it be asynchronous because you need to keep track what your async code is doing and without another thread, it is impossible to track 2 or more code at a same time?
Ah.. here's the thing:
JavaScript is single threaded, but it has a lot of spare time on its hands.
When it is waiting for something to load out off the network, or its waiting for something off disk or waiting for the OS to hand something back to it, it can run other code.
setTimeout(function() {
// Do something later.
}, 1000);
While it is waiting for that timeout to return an execute that code, it can run code from OTHER timeouts, or network calls or any other async code in the system. It only runs ONE block of code at a time, however, which is why we say it is single threaded.
That thread can just bounce around. A lot.
And, as others have said, there are web workers and service workers, but those run VERY isolated from your main thread. They can't change values behind your main thread's back.
Updated per comment
The event loop works by:
Waiting for an event
Handling that event.
JavaScript is, indeed, blocked while handling an event. While code is running, nothing else in that page (assuming browser main thread) can run.
It isn't a literal event loop as you would have in C or C++, not as far as the JS is concerned. It's just events waiting to happen.
/// Sample code
document.addEventListener("click", function() { /* Handle click */ });
window.addEventListener("load", function() { /* handle load */ });
In this case, have two event listeners in our code. The JS engine will compile, then execute those two statements. Then, for all intents, "sleep" while waiting for something to happen. In reality, that same thread may handle various house-keeping tasks like drawing the HTML page, listening for move movements and emiting all sorts of events, but that doesn't matter for this discussion.
Then, once the rest of the page is loaded, the browser will emit a load event, which will be caught the listener and some more code will be run.
Then it will go back to idling until someone clicks on the document, then more code will run.
If we change the code to this:
document.addEventListener("click", function() {
while(true);
});
then when someone clicks on the document, our thread will go into an endless loop and all browser activity in that window will cease. Might even freeze the entire browser, depending in which one you are running.
Eventually, the browser will give a chance to kill that task so you can have your system back.
Latest Update
If you are aware of Webassembly there is a proposal in place for Threads via natively compiled modules
pthreads-style read this git issue tracker link(1073)
In continuation with #Jeremy J Starcher answer.
Javascript is always been single threaded runtime using asynchronous, non-blocking and event-driven models of execution.
To know more about event loop execution in JS i highly recommend you to watch this
Youtube video. Simply superb explanation by Philip Roberts.
Good olden days, developers would beat around the bush to achieve similar to thread model using
setTimeout with 0 - milliseconds or setIntervals : Basically instructing the engine to take up non-trivial tasks when the engine goes idle or wait mode during a http request or execute the code by switching back and forth in intervals kinda round-robin fashion.
Hidden Iframe : Run a JS code in a sandbox with a bridge to communicate from parent to iframe and vice versa. Technically Iframe doesn't run on separate thread but gets things done as a fake thread.
Fast forwarding [ >>> ] to Multi-threading models by ECMA:
Off late things have changed with the requirement to spawn a thread in JS engines to offload few smaller logical tasks or a network proxy task to a separate thread and concentrate on UI driven tasks like presentation and interaction layer on main thread, which makes sense.
With that requirement in mind ECMA came up with two model/API basically to solve this.
1. Web Worker: (SIC - Mozilla)
Web Workers makes it possible to run a script operation in background
thread separate from the main execution thread of a web application.
The advantage of this is that laborious processing can be performed in
a separate thread, allowing the main (usually the UI) thread to run
without being blocked/slowed down.
[ WebWorker can be split into two ]
Shared Worker
The SharedWorker interface represents a specific kind of worker that
can be accessed from several browsing contexts, such as several
windows, iframes or even workers. They implement an interface
different than dedicated workers and have a different global scope,
SharedWorkerGlobalScope.
Dedicated Worker : Same as Webworker, created using Worker() API but uses DedicatedWorkerGlobalScope
Worker is an object created using a constructor (e.g. Worker()) that
runs a named JavaScript file — this file contains the code that will
run in the worker thread; workers run in another global context that
is different from the current window. This context is represented by a
DedicatedWorkerGlobalScope object in the case of dedicated workers
2. Service Worker (SIC - Mozilla)
Service workers essentially act as proxy servers that sit between web
applications, and the browser and network (when available). They are
intended to (amongst other things) enable the creation of effective
offline experiences, intercepting network requests and taking
appropriate action based on whether the network is available and
updated assets reside on the server. They will also allow access to
push notifications and background sync APIs.
One example usage would be in PWA - Progressive web app to download scripts, lazy loading purposes of assets.
Read this article by Eric Bidelman on HTML5Rocks good explanation about the code itself and implementation
JavaScript may be "single-threaded" (I'm not sure this is really the case), but you can use/create webworkers to run javascript outside the main thread.
So you can run two pieces of code at the same time in parallel.
I think it is wrong to say that a language is this or that when what we really mean is that our programs are this or that.
For example: NodeJS is single-threaded and can run code asynchronous because it uses an event-driven behaviour. (Something comes up and fires an event... Node deals with it and if it is something like an online request, it does other things instead of waiting for the response... when the response comes, it fires an event and Node captures it and does whatever needs to be done).
So Javascript is...
single-threaded? No, as you can use WebWorkers as a second thread
non-blocking? You can write code that blocks the main thread. Just build a for that executes a hundred million times or don't use callbacks.
asynchronous? No, unless you use callbacks.
concurrent? Yes, if you use webworkers, callbacks or promises (which are really callbacks).
Related
I am building a small two-player gaming app. It is very important to send data from one player to another in real-time and for that sockets look promising.
A few places I read that javascript doesn't support multithreading. Then what can be possible solution for both side communication as two threads will be needed to manage C1->C2 and C2->C1 communication in parallel.
My high-level architecture looks like
How can three threads can be managed by javascript in a webpage? One for C1 to C2 message transfer, second for C2 to C1 message transfer and third for user interface?
A JavaScript program runs on a single thread of execution using a "run to completion" semantic.
Operations that would normally block in other languages are non-blocking, and simply handed off to the host (in this case, the browser), with your program notified of progress asynchronously via events.
When the host raises an event to be consumed by your program (eg. an inbound message), it puts a notification of that event in a queue as a "job". When that job reaches the front of the queue, and as soon as the call stack is empty (ie. the current script being run has run to completion), the JavaScript runtime dequeues the job and invokes the continuation function associated with it (ie. the part of your program configured to handle the event).
Your game will be sending messages over the network (eg via WebSocket). Your program will simply hand each message to the browser. This process is not computationally expensive or time consuming. The browser is multithreaded and will handle the low-level and time consuming networking concerns for you.
JavaScript is an event-based language. If you wish to be notified of future events related to a message you sent, then you can supply a callback (or use a promise) to be invoked by the runtime in the future at the appropriate time, rather than simply waiting for it. In this way the time available on the main thread of execution is used efficiently.
Your game loop will probably use requestAnimationFrame. That gives you about 16 milliseconds of computation per frame. Computation of game state might take a few milliseconds. Handling scheduled and time-based events might take another few milliseconds. Finally rendering needs some time too. In effect your program cooperatively multi-tasks on a single thread of execution.
For long-running, computationally expensive tasks you can use the Worker API to create new threads of execution with which you can communicate in a controlled way, but you will probably not need this here.
There is plenty of information online already about this topic. Search for "how the event loop works".
Relevant questions here, here, here, here, and here.
I've got no problem with events and callbacks, synchrony/asynchrony, the call stack and the queue.
However, as I understand it, other servers make a new thread for each connection which contain both the blocking request and handler for the response of that request where as in node this handler would be passed to the main thread as a callback. The ability of this kind server to handle multiple requests is therefore limited by it's ability to create and switch between multiple threads.
When Node receives a blocking request it sends it into asynchrony land while it carries on processing the main thread. What happens in asynchrony land, doesn't a thread still need to be created to await the response for that request and then to sent the event to node event loop? If so, why isn't Node as limited by the server's ability to create and switch between threads? If not, what happens to the request?
I think there's some confusion over how the event loop actually works. NodeJS doesn't "receive a blocking request" and "send it into asynchrony land". It's asynchronous to begin with - unless you call a ...Sync() pattern function, EVERY call and EVERY operation is async. Confusingly, once you are inside your CODE, EVERY operation is synchronous.
It's a "cooperative multitasking" approach - all calls to the system are expected to "start the ball rolling" and return immediately, while your own code is suppose to do what it needs to do as quickly as possible and yield control back to the JSVM (by returning from your function).
To understand how this works when you're dealing with network communications, you need to go back in time to before threads really even existed. In the early days, if you had multiple network connections, your single-threaded process would have to put together a list of all the sockets it wanted information on (such as "has data arrived for me to read?"), and ask the OS if that was true by calling select(). This would a yes/no for each socket for each question. This was typically done in a while() loop that ran until the program was terminated. You would ask for a list of sockets with new data, read that data, do something with it, and then go back to sleep, over and over again.
NodeJS is far more sophisticated but this analogy works well for it. It has a main "event loop" that is constantly sleeping until there is work to do, then waking up and doing it.
Everything that you do comes from, or goes into, this channel. If you write data to a network socket, and ask to be notified (called back) when it's done, NodeJS passes your request to the operating system and then goes to sleep. You stop running. Your context is saved - all your local vars are saved. When the OS comes back and says "done!", NodeJS checks its list and sees you wanted to know about this, and calls your function, reloading your context so all your local vars are where you need them.
To be very clear, it is entirely possible that when the data is finished being written to the network, and the OS notification comes back for that, NodeJS is busy with other work! NodeJS won't "create a thread" to handle it - it'll ignore it completely until it gets some free time! It won't be lost... it just won't be handled "yet".
This drives programmers used to threading models nuts - it seems illogical that this constant state of never immediately responding to an incoming event "until it has a chance" could possibly be efficient. But software architectures are often deceiving. Threading models actually have fairly high overhead. CPU core counts aren't infinite - the entire computer as a whole is doing plenty of work all the time. Threads aren't free - just because you make one doesn't mean the CPU itself has time to do anything with it. And the overhead of thread creation and management often means an efficiency loss.
Old-school event-loop models eliminate this overhead. When things go badly like you have an infinite loop in your code, they can behave very badly - often locking up completely. But when things are going well they can actually be a lot faster, and many benchmarks have shown that well-written NodeJS modules can perform as well as or even better than similar modules in other languages.
In summary, the most common confusion in NodeJS is what "async" really means. A good way to think of it is that in threading models, programmers are expected to be "bad"/simplistic (write blocking code and just wait for things to return) and the core VM or OS is expected to be "good"/smart (tolerate this by making threads to handle async work). In NodeJS, programmers are expected to be "good"/sophisticated (write well-structured async code), allowing the JSVM to focus on what it does best and not need as much magic to make things work well. Well-used, NodeJS puts a lot of power in your hands.
I'm new to Node and try to understand the non-blocking nature of node.
In the image below I've created a high level diagram of the request.
As I understand, all processes from a single user for a single app run on a single thread.
What I would like to understand is the how the logic of the event loop fits in this diagram. Is the event loop the same as the processor pipeline where instructions are queued?
Imagine that we load an app page into RAM that creates a stream to read from by the program:
readstream.on('data', function(data) {});
Instructions for creating the readstream and waiting for data to occur: does this instruction "hang" in a register (waiting for the I/O to finish) in the processor whereas in a multithreaded environment, the processor just doesn't take new instructions from the RAM until the result of the previous I/O request has been returned to the RAM?
Or is the way I see this entirely/partially wrong?
Just a supplementary (related, perhaps stupid) question: run different users on different threads on the server and isn't the single threaded benefit only for a single user?
I'm new to this type of detail, so excuse me if this question doesn't entirely make sense to you. But understanding this seems essential for me before moving forward.
Event-driven non-blocking I/O relies on the fact that modern operating systems have a 'select' method that performs polling at the O/S level (not wasting CPU cycles). The select method allows you to register callbacks for certain I/O events. This tends to be much more efficient than the 'thread-per-connection' model commonly used in thread enabled languages. For more info, do a 'man select' on a Unix/Linux OS.
Threads and I/O have to do with operating system implementation and services, not CPU architecture.
Operations that involve input/output devices of any kind — mass storage, networks, serial ports, etc. — are structured as requests from the CPU to an external device that, by one of several possible mechanisms, are later satisfied.
On top of that reality, operating systems provide alternative programming models. In one model, the factual nature of input/output operations are essentially disguised such that executing programs are given an API that appears to be synchronous. In a C program, a call to the write() system call will cause the entire process to delay until the operation has completed.
Another programming model more closely exposes the asynchronous reality of the system. That's what Node uses. Operating systems provide ways to initiate long-duration asynchronous operations, along with ways for a process to either check for results or to block and wait for results. In Node, the runtime system can juggle lots of separate operations because the entire model is based on code running in response to events. An event can be a synthetic thing (such as the "event" of a Node module being loaded and run initially), or it can be something that's a result of actual asynchronous external events. In the case of input/output operations, the Node runtime waits for operating system notification and translates that into an event that causes some JavaScript code to run.
Chrome was the last of the big trio (IE, Firefox, Chrome) to deprecate running synchronous XMLHttpRequest calls on the "main thread" (as Firefox calls it). Some browsers have also completely removed the ability of setting the .widthCredentials option for synchronous requests on the main thread.
After searching far and wide, I couldn't find enough information to precisely identify which code will run on the main thread, and which will not.
It is obvious that javascript included via script tag (inline or with src) is on the main thread.
And a synchronous XHR which runs inside the callback of an asynchronous XHR would not be running on the main thread.
But how about other scenarios? Mouse events, touch events, various document events? How to tell without trying everything? It would be nice to avoid making everything asynchronous and a callback hell.
Please attempt a thorough answer.
Edit:
W3C spec warning:
Developers must not pass false for the async argument when the JavaScript global environment is a document environment as it has detrimental effects to the end user's experience. User agents are strongly encouraged to warn about such usage in developer tools and may experiment with throwing an "InvalidAccessError" exception when it occurs so the feature can eventually be removed from the platform.
Edit 2:
Clarification:
There are situations where calling code must either wait for all racing simultaneous async calls to finish (using some counters or state tracking variabiles for each call), or have them chained using callbacks. Each situation sucks. For example, I have a JSONRPC client which needs to dynamically create callable functions by interrogating a reflection API.
It is over the hand to have all implementing code (UI, or NOT) run inside the callback of yet another a library, especially if it has to be done on multiple pages, and if the library has to behave as a simple definition (hide that is running code at define time). This is just an example of complexity, I am not asking for a solution to it, but a general clear explanation of how browsers decide which is the main thread.
As you have cited the W3C spec, it's easy to explain what you are hunting after:
Developers must not pass false for the async argument when the
JavaScript global environment is a document environment as it has
detrimental effects to the end user's experience.
What they mean document environment is explained in the processing models:
This specification describes three kinds of JavaScript global
environments: the document environment, the dedicated worker
environment, and the shared worker environment. The dedicated worker
environment and the shared worker environment are both types of worker
environments.
Except where otherwise specified, a JavaScript global environment is a
document environment.
A "document environment" is therefore the global JavaScript environment of a page, i.e. the window that you see. Every JS global environment is single-threaded. Everything (really everything, you considered: Mouse events, touch events, various document events) runs in this environment. This is probably what Gecko considers a "main thread".
It would be nice to avoid making everything asynchronous and a callback hell
Making something asynchronous doesn't shift work from the main thread. It just defers it, making it possible for other events to run while you are waiting. If there is an asynchronous api for what you want to do (i.e. does processing in the background), use it. Make everything asynchronous.
There are enough techniques (e.g. promises!) to avoid a callback hell, which is just a sign of bad code.
Shifting work off the "main thread" requires you to create a new environment - a web worker. In that, you can do as many synchronous XMLHttpRequests as you want without being disturbed.
Each browser is free to implement its own threading model as it sees fit. Different implementations will handle threading differently.
It is safe to say that if you are to block execution with JavaScript that you are doing something you shouldn't be. Even if you don't hang up the UI, browsers these days will prompt the user to abort your script. If you stay within a reasonable amount of blocking processing in your script, this isn't an issue. Synchronous XHR is something you should never do, as it isn't necessary and the time for which the thread will block is unpredictable.
I have a general question that I'm having trouble grappling with about web workers. I understand that they engage in background calculations in another thread so they take off the load from the window that the user is in.
However I'm confused on whether that 'other thread' means something like having a different program running on the computer, having a separate browser open, or whether it's like a new tab in the same browser. I feel that this is more of the latter case, but I'm not 100% sure about that and I can't find good explanations.
What implications does this have on the limitations of what we can do with web workers?
Thanks in advance!
A webworker works like an independent thread of execution. Multiple threads can run at the same time in a computer process. If there are multiple processors, these multiple threads can actually run at the same time. If there is only a single processor, then the OS on the computer handles time slicing between the different threads such that each one runs for a short while, then the next one runs and, to the casual observer, they appear to be running at the sametime.
In a browser, a webworker is indeed a thread of execution that runs independently of the browser window thread (of which there is one for each browser page that is open in the browser). The browser window thread has a number of limititations. The main limitation is that it only processes user events (mouse movement, mouse clicks, keyboard events, etc...) when no javascript code is also running in the main browser thread. So, if you were to run some long running javascript code in the main browser thread, the browser will "appear" to be locked up and won't process any user events while that javascript is running. This is generally considered a bad user experience.
But, if you run this javascript in a webworker, it can go do it's long running thing without blocking the processing of events in the main browser window thread. When it finishes its long running computation, it can then send a message to the main browser window thread and the result can be processed (e.g. displayed in the page or whatever the particular action is).
There are ways to work-around the limitations of the main browser thread by breaking your work into small chunks and executing small chunks of work on a recurring timer. But, using a web worker thread can significantly simplify the programming.
Web workers themselves cannot access the browser page in any way. They can't read values out of it or modify it - they can't run animations, etc... This limits their usefulness a bit to tasks that are more independent from the page. The classic use is some long running calculation (e.g. analyzing data from an image, carrying out ajax calls, doing some complex calculation, etc...). Web workers can communicate with the main thread via a messaging system. It's kind of like leaving a voicemail. The webworker calls up the main thread and leaves a message for it. The next time the main thread has nothing to do, it checks to see if there are any messages from web workers and if so, it processes them. In this way, the main thread and the web worker thread can communicate, but one cannot interrupt the other while it's doing something else.