Здравствуйте, namespace, Вы писали:

N>Могу ошибаться, поправьте.
N>Раньше асинхронные вызовы не создавали дополнительных потоков.
N>И делались они, в основном, для записи и чтения.
Как сделать вызов, всегда решаешь ты сам. Да, в дотнете — по умолчанию все идет на пул потоков. И то, по сути все под контролем на стороне и вызывающего и реализующего. Вместе с тем, там есть и контексты синхронизации, которые необходимы как и для любых UI фреймворков, так и для IIS / ASP.NET (где твои методы контроллеров уже вызываются на пуле потоков, не дотнетном и ты можешь или заблокировать поток (чем изрядно уменьшить реальную достижимую нагрузку), или сделать await на его контексте синхронизации без ConfigureAwait(false)) и это все равно вызывало кучу проблем. В современном хосте и/или иных хостах вокруг дотнет коры — там все идет на пул потоков, и париться не надо.

N>В потоке окна писали пакет размером с предполагаемый буфер.
N>Затем цикл обработки сообщений окна продолжал работу, периодически проверяя ответ от железяки.
N>Все это внутри самой Windows было.
Цикл обработки сообщений обычно "живет" в основном потоке процесса. Это не эфемерный код со стороны — это клиентский код который содержит любая Win32 программа. Когда "окно" получает сообщение — это результат вызова в этом самом потоке DispatchMessage.

N>Те был один поток и при этом окно не подвисало при чтении/записи.
N>Но считать, перебирать, сортировать там нельзя было категорически.
Так же само сейчас. На всех основных платформах.

N>Вроде, я где-то читал при появлении asyn-await, что он реализован именно так. Или так только задумывалось.
Пул потоков / библиотека TPL кооперативно разребает накопленные задачи, таким образом не теряя время на синхронизацию/или переключения.

N>По факту создаются потоки. И как-то синхронизируются с основным потоком.
В хроме кроме пула потоков, есть еще специальные потоки: UI, IO, File (blocking) и т.п. — в них сидят такие же самые циклы обработки сообщений. Но, попытки вызова методов не на тех потоках всегда больно бьет по рукам. Это с одной стороны дисциплинирует, с другой стороны вводит дохрена неявности, потому что "этот метод может быть вызван на любом потоке" как правило означает "я проверяю на каком потоке я и маршалю вызов на другой поток, но когда он завершится — спросите у void".

N>Но это уже не та асинхронность без лишних потоков в ожидании. Любо Windows нам так их показывает.
Web, TypeScript — чистая однопоточность, тот же самый async/await. Раньше приходилось костыли изобретать, весьма неудобные.

UPD: Это галопом по галактике, очень грубо. Я едва понял что ты там написал.