Does JavaScript create threads for non-blocking AJAX?
By all accounts, JavaScript is essentially single-threaded, but it can run asynchronously. I wonder how a single threaded model like this handles AJAX requests that don't block?
Suppose a non-blocking AJAX request is triggered in the browser but does not receive an immediate response. If the event loop continues to check for the response, is execution blocking? The event loop keeps checking its status and "re-adding" the task to the back of the macro job queue when there is no response?
From what I understand, Node.js silently spawns threads to handle I / O operations that access disks, databases, network sockets, etc. Does JavaScript in browsers have streams to handle AJAX too?
A similar question can be asked about the following:
var img = new Image();
img.onerror=function(){alert('error: '+this.src);}
img.onload=function(){alert('image loaded: '+this.src);}
img.src='path/to/image.jpg';
Does the last line of code above describe spawning an extra thread because the assertion appears to be non-blocking?
source to share
The general perception is that JavaScript is single threaded, but it can run asynchronously.
It is true that JavaScript is defined so that only one thread can execute at any given time within a scope . (Scope is the global environment and its associated objects; for example, a window / tab [in browsers].) You can have multiple active threads (in different windows or through web workers) and they can communicate with each other (through ) or even share some memory ( ), but they cannot access the same area at the same time. Efficient single-threaded storage of regions avoids a huge number of concurrent programming errors. postMessage
SharedArrayBuffer
I wonder how a single threaded model like this handles non-blocking AJAX requests?
JavaScript allowing only one thread in a JavaScript environment does not mean that the host (browser) is single-threaded. The asynchronous AJA request is passed to browser network processing.
JavaScript works on the basis of a job queue (the HTML5 expert calls it a job queue, but the JavaScript spec says "jobs" is just a name). The JavaScript thread picks up a job from the queue, runs it to the end, and then fetches the next job, if any. (This is a little more complicated than this, but this is the basic idea.) While a thread is executing a job, no other thread can start another job in the same scope.
So when the ajax request completes (success, timeout, etc.), the Browser (possibly on a non-JavaScript thread) puts the job in the JavaScript job queue to invoke the ajax callback. The JavaScript thread takes this work and calls the callback.
It's worth noting that this is exactly what it does in response to other things that happen, such as when the user clicks something.
Let's say a non-blocking AJAX request is triggered in the browser, but does not immediately receive a response. If the event loop continues to check for the response, is execution blocking?
The key is that the thread is not constantly checking the response. The thread is just looking at the job queue. The browser network handler handles the completion of network requests.
Explicit This was clearly stated in ES2015, but this has been the case in normal environments (browsers, Node.js) for a few years before. There were JavaScript frameworks that allowed multiple threads in the same scope (for example, Rhino running JavaScript on the Java VM), but these were not considered important enough to prevent ES2015 from adding this requirement, and this allowed precise semantics to be defined around several new features that were it would be much harder to point out if it were possible while remaining taciturn about the flow.
source to share
Disclaimer: The following text is just guessing. I don't know what I'm talking about.
Actually, processors can also handle asynchronous events. This is called a hardware interrupt. So whenever a new message is received in your device's input module, it triggers such an interrupt, and the processor will jump to a specific memory location called an interrupt handler, which then starts a new thread to handle the input, and then jumps back to the position from which it was interrupted. So basically, if the request was scheduled, the js event loop, the browser thread and even the cpu can stop for a second (very rarely). If a response arrives, the internet module wakes up the processor and starts an interrupt handler, which starts the kernel module to process it, which then hits the browser, which parses the request and kicks off the js event loop, passing the ajax request to qeue.So in fact it is even possible if the browser is just running on a single thread (which it doesn't).
source to share