How does asynchrony work anyway?

Question

JavaScript

Hello. I'm still trying to figure out for myself how asynchrony works under the hood.

1. Do I understand correctly that the full name of asynchrony is Asynchronous I / O and that I / O operations can be asynchronous?
   
2. Based on the first question and the concept of "Everything is a file" is all asynchrony based on the OS multiplexed I / O API (pool / select / epool | KQueue | something similar in Windows) that the OS provides?
   Judging by, for example, the description of NodeJS, or rather libuv which implements eventloop

libuv is a multi-platform C library that provides support for asynchronous I/O based on event loops. It supports epoll(4), kqueue(2), Windows IOCP, and Solaris event ports

my guess is correct.

I understand that it looks like there is no question here, I just want to make sure and get an answer from knowledgeable people whether I am right in what I wrote or wrong.

Answer 1

What is written is asynchronous I/O. There may also be an asynchronous computation that runs on a separate thread. There is also a stupid option when synchronous I / O is launched in a separate thread that just waits.

Answer 2

Mimicking one person, asynchrony is cooperative multitasking plus an event loop.
Simplified, there is a set of functions that can pause and resume their execution - coroutines.
Coroutines usually pause their execution after an I/O request, but they can also for other reasons - for example, just waiting, or waiting for another coroutine to complete, or something else.
The core of an asynchronous program is the "reactor" pattern - the work cycle. In the context of client-side JS, this is the browser's work cycle, in the context of a node - something separate, I suppose (did not work with the node).
The loop does the following:
- waits for one of the I/O operations or wait (any) to complete
- determines which coroutine was waiting for this operation
- transfers control to it
- the coroutine does its job, processing the result of the operation
- then the coroutine either ends or schedules another operation. And the cycle resumes.
This is where all the pros and cons come from. On the one hand, switching between coroutines occurs at explicitly specified points in time, so there is less fuss with synchronization.
On the other hand, you can't parallelize long calculations like that - only input / output. Well, or in a long calculation, pause from time to time, but there will still be no gain. So it only makes sense for IO-bound programs.

Answer 3

Anything can be asynchronous, just for I / O there are means in the OS, for the rest you need to write it yourself (using multithreading or another version of parallel execution) or use libraries.
In general, the principle is this: you give a task and this task is somehow executed, regardless of your thread, there must be a mechanism for notifying / polling about the state of the task, returning errors / exceptions / results.
Of all the asynchronous APIs I've seen, perhaps the most "asynchronous" is "POSIX asynchronous I / O", this is when you call an asynchronous read / write, and a signal is used for feedback (there is nothing similar in Windows). It is the most asynchronous because the main thread does not need to poll the state of the task in any way - the system itself interrupts the thread with a signal at an arbitrary moment. This mechanism is rarely used. The most common are select/poll/epoll, the same libuv uses poll (in Windows IOCP).

Answer 4

I liked the short book
Asynchronous Programming in C# 5.0 | Davis Alex
Everything is laid out there not only under c#, the concept itself
https://www.ozon.ru/product/asinhronnoe-programmir...