Lesson 8 - Event Loop (Returning a Promise)

[RamanSB]

Hi All,

I found it quite interesting when we created the listenForTransactionMine function and the output of the console.log order was not as expected, Patrick mentioned the Event Loop, can someone please shed more light on what the Event Loop is and what exactly it is doing in the context of lesson 8.

Reading this article on educative it mentions JS is a single threaded language but supports async programming.

Am I write in asserting the following statements:

• Javascript is single threaded because function calls on the callstack are executing synchronously/sequentially (in order - one at a time).
• According to the article without this 'Browser API' JS wouldn't be able support asynchronous functionality?

I am trying to understand exactly how JS works in both cases of:

• Async Functions
• normal synchronous functions
  specifically regarding the event loop, the call stack, event queue & this 'browser api' mentioned in the article?

[JamesMckenna]

Javascript is single threaded because function calls on the callstack are executing synchronously/sequentially (in order - one at a time).

No, not really. JavaScript is single threaded by design. The result is that functions are executed synchronously / sequentially.

This is actually a fairly difficult concept to explain, but I'll give it a shot.

The JavaScript runtime engine is single threaded, period. That means two function cannot run in parallel, a JavaScript runtime process can only have 1 execution thread and can ONLY execute 1 function on the stack at a time.
The stack is "Last In First Out" (LIFO). Meaning the last function that was put on the stack, is the function that needs to complete before the function beneath it can execute. Hence, synchronously / sequentially.

In a web browser:
A Browser Tab, has only 1 JavaScript runtime, can only have 1 stack.

In other runtimes like .NET or the Java Runtime Environment, this would be analogous to the UI thread. The difference is, in other runtimes a new thread can be created. Think of it like each thread can have a "stack". Creating a new thread in a runtime environment like .NET, allows for functions to be run on the second thread (in parallel), keeping the first thread free to execute UI only code. This keeps the UI from lagging or freezing up. A long-running function is running on the second thread. This is what known as multi-threading (but in today's .NET, developers should use the ThreadPool Manager, async functions, Tasks, ect... and seldom create and destroy threads manually, let the runtime figure it out).

JavaScript Promises / Async Functions are not executed on the JavaScript runtime UI thread (Browser Tab). What happens is behind the scenes, the web browser will ask the OS for another process (Task Manager process on Window). On that other process, a second JavaScript engine / runtime, is started. The browser will use a protocol known as "Inter-process Communication" to communicate between the first runtime (UI thread / Browser Tab) and the second runtime executing on the second process. When a Promise is called, the first process passes it to the second, for the second to run it - leaving the first to continue executing the functions on it's stack, from top down, LIFO - THIS IS IMPORTANT.

When the second process finishes executing the Promise that was passed to it, it tries to return the results to the first thread / process (UI, Browser Tab). IF AND ONLY IF the first thread's stack is empty, does the second function's returned value get place onto the first thread's stack. At that point, the first thread (Browser Tab) can make use of the Promise's returned value (rejected or resolved, it will be pending until returned to thread 1's stack from second runtime).

So if the first stack is empty, the returned value from the second is placed on top. If the first thread's stack ISN'T EMPTY, the Promise's return value WAITS IN LIMBO until the first stack is empty. It is possible to have many Promise's return value WAITING IN LIMBO. This LIMBO is a Queue data structure or, "First In First Out" (FIFO).

So for every "Tick" of the processor, the Browser Tab's (UI thread) stack is checked to see if it's empty, or if there is a function that needs to be executed. If empty, then it retrieves a Promise's returned value and places it on it's stack. At which time it can do something with that Promise's returned value.

This is known as the Event Loop.

This is the understanding I have come to after developing web apps and electron apps. For anyone reading this, please correct any inaccuracies.