How does JS Promises works being single threaded

Question

Javascript is single threaded. What I understand from this is if JS i executing on line of code lets say a function. It cannot go to the next line unless that function has been removed from the stack.

With that being said, I do not understand, how promises let us execute other code blocks down the road, while the interpreter is still resolving the promise code.

I am a noob in JS so I am trying to understand the underlying implementation.

I saw an example PHP implementation of Promises and the idea is that PHP can fork a separate process in a different thread that sends back signal to the main thread when the async code has been executed.

Does it work the same way in Javascript ?

Thanks

Answer 1

Parallel or out of order or asynchronous execution is not really tied to number of threads. Think of it. A single thread can still do the switching and do n things at same time, in bits and pieces. Like a software based CPU.

It's really how the execution platform is implemented. You can have an illusion of such processing via an event queue and a single looper thread that works on that queue.

In case of JavaScript engines, you can think that for every async operation defined on any line in source code, the engine does not wait to complete that operation, rather, simply place it in the queue and cater to it from time to time, until it is completed.

The promised (or future) values contain nothing when the line is executed, and next line is evaluated. Only some time later the values "resolve" and everything depending on that value is also resolved, and so on, until everything is resolved and the queue is empty. Think of a graph being collapsed back to root as values become available and pending calculation complete.

Answer 2

Promises in JS are a way to do asynchronous programming, which is not the same as multithreading. Essentially, in synchronous single-threaded code, when there's some some sort of IO, the processor just issues an instruction to other hardware, and that's it. After that, it just sits there doing nothing (at least from the perspective of your program), and waits until this other hardware is finished - and this usually takes a lot of time (in the sense that the CPU could accomplish a significant number of other tasks during that period). So there's no extra thread in the usual sense of the word, but there is some processing happening in parallel (it's just not happening in the CPU).

With asynchronous programming, you essentially assign a callback to be executed when the task succeeds (or fails), call some code to "fire off" the async operation, and then you continue with your own business, doing some other useful work in the meantime. When the other hardware completes the task (or fails), the CPU gets notified and executes the appropriate callback.

You can read more about how the CPU handles asynchronous events here.

See also: Concurrency vs Multi-threading vs Asynchronous Programming: Explained.

Answer 3

The asynchronous task may be forked by the JS runtime, for example when only external systems are involved, but it may also get started/executed when there is no more other code to run. In the first case at least your completion callback will be scheduled for later execution. In JS this happens when the call stack becomes empty and the so called event loop executes the next scheduled task or processes observed events (like clicks). That's why in JS you may not write infinite loops or other constructions which lead to never-terminating calls.