Is my understanding of asynchronous operations correct? [closed]

Answer 1

Almost correct but not quite.

If you are talking about "asynchronousness" the word in the English language then it just means that things can happen out of order. This concept is used in a lot of languages including multithreading in Java and C/C++.

If you are talking about the specific concept of asynchronousness as it relates to node.js or asynchronous I/O in C/C++ then you do have some misunderstandings in how this works at the low level.

A problem can occur if a piece of code takes a long time to complete. This is because i) it stops code below from running and it might be nice to run this whilst the hard code loads in the background. And ii) Indeed, JS might try to execute the code below before the hard code’s finished. If the code below relies on the hard code, that’s a problem.

When talking about javascript or asynchronous I/O in C/C++ (where javascript got its asynchronousness from) this is not true.

What actually happens is that waiting for something to happen may take a long time to complete. Instead of waiting why not tell the OS to execute some code (your callback) once that thing happens.

At the OS level most modern operating systems have API that let you tell it to wake your process up when something happens. That thing may be a keyboard event, a mouse event, an I/O event (from disk or network), a system reconfiguration event (eg. changing monitor resolution) etc.

Most traditional languages implement blocking I/O. What happens is that when you try to read something form disk or network your process goes to sleep immediately and the OS will wake it up again when the data arrives:

Traditional blocking I/O

 time
  │
  ├────── your code doing stuff ..
  ├────── read_data_from_disk() ───────────────────┐
  ┆                                                ▼
  :                                        OS puts process to sleep
  .
  .                                         other programs running ..
  .
  :                                            data arrives ..
  ┆                                        OS wakes up your process   
  ├────── read_data_from_disk() ◀──────────────────┘
  ├────── your program resume doing stuff ..
  ▼

This means that your program can only wait for one thing at a time. Which means that most of the time your program is not using the CPU. The traditional solution to listen to more events is multithreading. Each thread will seperately block on their events but your program can spawn a new thread for each event it is interested in.

It turns out that naive multithreading where each thread waits for one event is slow. Also it ends up consuming a lot of RAM especially for scripting languages. So this is not what javascript does.

Note: Historically the fact that javascript uses a single thread instead of multithreading is a bit of an accident. It was just the result of decisions made by the team that added progressive JPEG rendering and GIF animations to early browsers. But by happy coincidence this is exactly what makes things like node.js fast.

What javascript does instead is wait for multiple events instead of waiting for a single event. All modern OSes have API that lets you wait for multiple events. They range from queue/kqueue on BSD and Mac OSX to poll/epoll on Linux to overlapped I/O on Windows to the cross-platform POSIX select() system call.

The way javascript handles external events is something like the following:

Non-blocking I/O (also known as asynchronous I/O)

 time
  │
  ├────── your code doing stuff ..
  ├────── read_data_from_disk(read_callback) ───▶ javascript stores
  │                                               your callback and
  ├────── your code doing other stuff ..          remember your request
  │
  ├────── wait_for_mouse_click(click_callback) ─▶ javascript stores
  │                                               your callback and
  ├────── your code doing other stuff ..          remember your request
  │
  ├────── your finish doing stuff.
  ┆       end of script ─────────────▶ javascript now is free to process
  ┆                                  pending requests (this is called
  ┆                                  "entering the event loop").
  ┆                                  Javascript tells the OS about all the
  :                                  events it is interested in and waits..
  .                                            │
  .                                            └───┐
  .                                                ▼
  .                                        OS puts process to sleep
  .
  .                                         other programs running ..
  .
  .                                            data arrives ..
  .                                        OS wakes up your process
  .                                                │
  .                                            ┌───┘
  :                                            ▼
  ┆                       Javascript checks which callback it needs to call
  ┆                          to handle the event. It calls your callback.
  ├────── read_callback() ◀────────────────────┘
  ├────── your program resume executing read_callback
  ▼

The main difference is that synchronous multithreaded code waits for one event per thread. Asynchronous code either single threaded like javascript or multi threaded like Nginx or Apache wait for multiple events per thread.

Note: Node.js handles disk I/O in separate threads but all network I/O are processed in the main thread. This is mainly because asynchronous disk I/O APIs are incompatible across Windows and Linux/Unix. However it is possible to do disk I/O in the main thread. The Tcl language is one example that does asynchronous disk I/O in the main thread.

A solution is: if an operation takes a long time to complete, you want to process it in a separate thread while the original thread is processed.

This is not what happens with asynchronous operations in javascript with the exception of web workers (or worker threads in Node.js). In the case of web workers then yes, you are executing code in a different thread.

But even the event-que can suffer from the same problem as the main-thread. If fetch1, which is positioned above fetch2, takes a long time to return a promise, and fetch2 doesn’t, JS might start executing fetch2 before executing fetch1

This is not what is happening. What you are doing is as follows:

fetch(url_1).then(fetch1); // tell js to call fetch1 when this completes
fetch(url_2).then(fetch2); // tell js to call fetch2 when this completes

It is not that js "might" start executing. What happens with the code above is both fetches are executed synchronously. That is, the first fetch strictly happens before the second fetch.

However, all the above code does is tell javascript to call the functions fetch1 and fetch2 back at some later time. This is an important lesson to remember. The code above does not execute the fetch1 and fetch2 functions (the callbacks). All you are doing is tell javascript to call them when the data arrives.

If you do the following:

fetch(url_1).then(fetch1); // tell js to call fetch1 when this completes
fetch(url_2).then(fetch2); // tell js to call fetch2 when this completes

while (1) {
    console.log('wait');
}

Then the fetch1 and fetch2 will never get executed.

I'll pause here to let you ponder on that.

Remember how asynchronous I/O is handled. All I/O (often called asynchronous) function calls don't actually cause the I/O to be accessed immediately. All they do is just remind javascript that you want something (a mouse click, a network request, a timeout etc.) and you want javascript to execute your function later when that thing completes. Asynchronous I/O are only processed at the end of your script when there is no more code to execute.

This does mean that you cannot use an infinite while loop in a javascript program. Not because javascript does not support it but there is a built-in while loop that surrounds your entire program: this big while loop is called the event loop.

On a separate note, I’ve read when chaining .then, that counts as one asynchronous operation.

Yes, this is by design to avoid confusing people on when promises are processed.

If you are interested at how the OS handles all this without further creating threads you may be interested in my answers to these related questions:

Is there any other way to implement a "listening" function without an infinite while loop?

node js - what happens to incoming events during callback excution

TLDR

If nothing else I'd like you to understand two things:

1. Javascript is a strictly synchronous programming language. Each statement in your code is executed strictly sequentially.

2. Asynchronous code in all languages (yes, including C/C++ and Java and Python etc.) will call your callback at any later time. Your callback will not be called immediately. Asynchronousness is a function-call level concept.

It's not that javascript is anything special when it comes to asynchronousness*. It's just that most javascript libraries are asynchronous by default (though you can also write asynchronous code in any other language but their libraries are normally synchronous by default).

*Note: of course, things like async/await does make javascript more capable of handling asynchronous code.

Side note: Promises are nothing special. It is just a design pattern. It is not something built-in to javascript syntax. It is just that newer versions of javascript comes with Promises as part of its standard library. You could have always used promises even with very old versions of javascript and in other languages (Java8 and above for example call have promises in their standard library but call them Futures).

Answer 2

This page explains Node.js event loop very well (since it's by Node.js):

https://nodejs.dev/learn/the-nodejs-event-loop

A problem can occur if a piece of code takes a long time to complete. This is because i) it stops code below from running and it might be nice to run this whilst the hard code loads in the background. And ii) Indeed, JS might try to execute the code below before the hard code’s finished. If the code below relies on the hard code, that’s a problem.

Yes, though to reword: having a user wait for code to resolve is bad user experience rather than a runtime error. Still, a runtime error would indeed occur if a code block was dependent on a variable that returned undefined because it had yet to resolve.

A solution is: if an operation takes a long time to complete, you want to process it in a separate thread while the original thread is processed. Just make sure the main thread doesn't reference things that the asynchronous operation returns. JS employs event-ques for this solution. Asynchronous operations are executed in an event-que which executes after the main-thread.

Yes, but it is important to point out these other threads are occurring in the browser or on an api server, not within your JS script. Also, async functions are still called in the main call stack, but their resolve is placed in either the job queue or message queue.

But even the event-que can suffer from the same problem as the main-thread. If fetch1, which is positioned above fetch2, takes a long time to return a promise, and fetch2 doesn’t, JS might start executing fetch2 before executing fetch1. This is where Promise.all is useful because it won't proceed with the next step in the asynchronous operation until both both fetch1 & fetch2’s promises are resolved.

Yes, a promise's resolve is executed as soon as the current function in the call stack resolves. If one promise resolves before another, its resolve will executed first event if it was called second. Also note that Promise.all doesn't change the resolve time, but rather returns the resolves together in the order their promise was executed.

On a separate note, I’ve read when chaining .then, that counts as one asynchronous operation so we can always guarantee that the subsequent .thenwill only execute when the .then before it has executed|resolved its promise.

Yes, though the newer and cleaner syntax is async await:

function A () {
  return new Promise((resolve, reject)=> setTimeout(()=> resolve("done"),2000))
}

async function B () {
  try {
    console.log("waiting...");
    const result = await A();
    console.log(result);
  } catch (e) {
    console.log(e);
  }
}

B();

And below shows the Node.js callstack in action:

function A () {
  return new Promise((resolve, reject)=> resolve(console.log("A")))
}

function B () {
  console.log("B");
  C();
}

function C () {
  console.log("C"); 
}

function D () {
  setTimeout(()=> console.log("D"),0);
}


B();
D();
A();
 

B gets called, C gets called, B resolves, D gets called, setTimeout gets called but its resolve is moved to the message queue, D resolves, A gets called, the promise gets called and immediately resolves, A resolves, the call stack completes, the message queue is accessed