GetCurrentThreadId это подтверждает?

Технически не существует способа "перебраться в главный поток" бесконечному
циклу или ожиданию прихода ответа от сервера без того чтобы этот главный поток
не поставить колом.


если бесконечный цикл не занимается майнингом, то возникают моменты, когда можно всунуть вызов await XXX, который запустит начало асинхронной операции, далее прервёт работу этого цикла и отыщет, чем бы ещё полезным можно было бы заняться основному потоку. Естественно, Sleep и WaitFor в таких циклах недопустимы!

Для каждой функции, в которой есть вызов await, автоматически создаётся класс, в котором хранится состояние выполняемой операции. Это затратно по сравнению с классической машиной состояний. Но гораздо эффективнее по сравнению с многопоточным подходом.

Угу, так же как TQuery.Open или epoll_wait. И в чём смысл тогда?..

[/quot]

Смысл в том, что когда вводят поддержку async/await, то для всего предлагают асинхронные аналоги, например, TQuery.OpenAsync, epoll_waitAsync. Иначе смысла нет никакого.

Не для всего оно бывает в природе. Лисковый I/O - да, сетевой - только под
Windows да и то весьма ограниченно.


Сетевой обмен где угодно уже давно есть в асинхронном варианте. .NET, Kotlin, Rust, Go, Python, NodeJS этом активно пользуются, и далеко не только в винде.

Я не надеюсь, что в Дельфи это когда-либо появится. Скорее всего никогда не появится.
Можно не переживать.

Не сопоставимо с теми преимуществами, которые даёт async/await в других языках. Тут пул потоков с его ограничениями, а там все в одном потоке.

О чём ты? В Delphi функция async называется ProcessMessages и есть от рождения.


Вот-вот! Одна Async-функция в Delphi уже есть. Осталось ещё миллион завезти для полноценности :)

Нет, осталось её вызов напихать в каждую сторую строку каждой первой функции.
Хотя постой-ка, местные хомячки именно так и делают.


Нет, выборка из очереди ожидающих асинхронных вызовов должна выполняться в методе TApplication.Run (и TForm.ShowModal).
Аналогично механизму TThread.Synchronize или TThread.Queue.
Собственно, примерно так и сделано в .NET, JS (и Python скорее всего).
В Go и Kotlin кардинально другой механизм.

Код ProcessMessages отличается от кода ShowModal только отсуствием показа окна.
Так почему "нет"-то?..


ProcessMessage это лишь вершина айсберга. И оно итак вызывается при необходимости.