It's explicit that the code is async, but how the asynchrony happens is completely implicit with async/await, and is managed by a runtime of some kind.

Kernel-style async code, where everything is explicit:

* You write a poller that opens up queues and reads structs representing work

* Your functions are not tagged as "async" but they do not block

* When those functions finish, you explicitly put that struct in another queue based on the result

Async-await code, where the runtime is implicit:

* All async functions are marked and you await them if they might block

* A runtime of some sort handles queueing and runnability

Green threads, where all asynchrony is implicit:

* Functions are functions and can block

* A runtime wraps everything that can block to switch to other local work before yielding back to the kernel

> Green threads, where all asynchrony is implicit:

which are no different from app POV from kernel threads, or any threads for that matter.

the whole async stuff came up because context switch per event is way more expensive than just shoveling down a page of file descriptor state.

thus poll, kqueue, epoll, io_uring, whatever.

think of it as batch processing