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

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

S>> Зачем? Еще раз для асинхронных методов достаточно downloadSomeDataAsync
·>А почему ты решил, что downloadSomeData — асинхронный метод, притом всегда? Вдруг он что-то просто из памяти достаёт в большинстве случаев?
Ты сам что то придумал и объясняешь.

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

S>>>>var res = await task; // или в синхронном варианте int res = task.Result;
S>>·>Вот зачем этот выбор? Более того, если ты воткнёшь тут "await", это значит сам метод придётся объявить async. И, возможно, это будет интерфейсный метод, тогда все его имплементации тоже придётся переделывать в async (даже если они простые и без всякой многопоточки/io). И все места вызовов этого метода. И где-то выше по стеку придётся ещё воткнуть await.
S>> Еще раз. витруальные потоки хороши для асинхронизации синхронного кода. Всё!
·>Неверно. Для параллельного исполнения, а не асинхронизации. Потоки в принципе для этого и придумывали.

Изначально асинхронность была придумана для асинхронного ввода вывода когда реальные потоки не используются.


S>>·>Зачем это всё?! Почему нельзя просто всегда писать "int res = task.Result"?
S>>·>Сабж?
S>> Затем, что мы останавливаем и поток для дожидания результата. Ведь он может выполняться значительно дольше чем код кода до task.Result.
S>>task.Result это для поддержки старого синхронного кода. Вот где преимущество виртуальных потоков.
·>Так что же плохого в старом синхронном коде при наличии виртуальных потоков? А хорошее, очевидно, есть. Синхронный код проще.

Ты не читатель. Я как раз и говорю, что виртуальные потоки хороши для старого синхронного кода.
Но для нового кода сложно использовать виртуальные потоки и Task так как задачи используются не только для асинхронного, но и параллельного кода.

То есть код надо переделывать на async/await.
По мне так C# значительно лучше Java.