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

S>>> и вызов через await Task.WhenAll
S>·>Это значит, что метод содержащий await Task.WhenAll тоже обязан быть async. Зачем??!
S> Затем, что это асинхронный метод. Для синхронных есть Task.WaitAll. Task можно создавать с опцией LongRunning
_Зачем_ он асинхронный?

S>>> Еще раз. витруальные потоки хороши для асинхронизации синхронного кода. Всё!
S>·>Неверно. Для параллельного исполнения, а не асинхронизации. Потоки в принципе для этого и придумывали.
S>Изначально асинхронность была придумана для асинхронного ввода вывода когда реальные потоки не используются.
Ок, уже лучше. А _зачем_ нужен асинхронный ввод-вывод? Что плохого в коде, который делает просто что-то вроде print(file.read(...)) или sendResults(sqlQuery.execute(...))?

S>>> Затем, что мы останавливаем и поток для дожидания результата. Ведь он может выполняться значительно дольше чем код кода до task.Result.
S>>>task.Result это для поддержки старого синхронного кода. Вот где преимущество виртуальных потоков.
S>·>Так что же плохого в старом синхронном коде при наличии виртуальных потоков? А хорошее, очевидно, есть. Синхронный код проще.
S> Ты не читатель. Я как раз и говорю, что виртуальные потоки хороши для старого синхронного кода.
С этим я и не спорю. И это офигенное преимущество — берём старый код и запускаем параллельно ничего не стесняясь.

S>Но для нового кода сложно использовать виртуальные потоки и Task так как задачи используются не только для асинхронного, но и параллельного кода.
А вот с этим спорю. В чём сложность-то?

S>То есть код надо переделывать на async/await.
Зачем надо?