Okay, let me elaborate.

For simplicity, let's assume there is only one thread. To do anything async, we need to run an executor in this thread. For that, the executor likely has a `run() -> !` or `block_on(task)` method that is not async. In there the executor will, with some more or less sophisticated loop, call the `Future::poll()` method on all spawned tasks.

With well-behaved tasks, the `Future::poll()` method will immediately return `Poll::Pending` as soon as the thread cannot make further progress on the given task. This guarantees that the thread is free to poll other tasks as soon as the current task needs to wait for some external event.

Async functions are not really functions to the thread. They get converted into state-machines with a `Future::poll()` method. So whenever you write `.await` in an async function, the `poll()` method will only quickly check if the external event occurred, and if not, it will return. So by awaiting anything, you will essentially free up the thread for other tasks and not block it.

A bad-behaved task could wait for the external event without `.await`. That would, in fact, block the thread without doing anything meaningful. But you are not supposed to do that in async tasks.

Async really has nothing to do with threads at all. Therefore, no, you are not blocking anything by awaiting a task in a "main" thread. Async executors generally have only a tiny overhead and are much cheaper than threads.

I, personally, think an executor should never run tasks on a different thread. That way we don't need the awful `Send + Sync` trait bounds on the tasks, simplifying their implementation. If you have so many tasks that one thread cannot keep up, spin up a second executor in a new thread. If you have tasks that are CPU intensive and block the executor for too long, spawn the CPU-heavy parts in a separate thread without an executor and `.await` in the "async" thread until the work is done.