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

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

S>>>> В JavaScript, под влиянием TypeScript пришли к тому, что await значительно лучше чем создание цепочек обратных вызовов
S>>·>Лучше, конечно. Но речь идёт про virtual threads. С ними не нужен ни await, ни цепочки обратных вызовов. Можно писать тупой синхронный код и выполнять на миллионах тредов.
S>> Речь вообще то идет про асинхронный код в общем. virtual threads не покрывает все возможные варианты. Я специально тебе вопросы задавал.
·>А ответы-то прочитал?

S>>virtual threads хороши для переноса синхронного кода. Но когда мне нужно параллельно запустить несколько задач , скачать с нескольких ресурсов и продолжить после завершения всех скачанных или первого скачанного, то как мне помогут virtual threads?
·>Ты, похоже, не понимаешь разницу между асинхронным и параллельным исполнением. Это ортогональные понятия.
·>Ты напишешь обычный синхронный код, который это всё сделает. В этом топике уже несколько раз пережевывалось, перечитай.
·>Например, для первого скачанного будет как-то так:
·>

·>Data downloadSomeData(List<URL> urls)
·>{
·>  try (var scope = StructuredTaskScope.open(Joiner.<Data>anySuccessfulOrThrow()))
·>  {
·>    for(var url : urls)
·>    {
·>      scope.fork(() -> service.download(..., url, ...));
·>    }

·>    return scope.join();
·>  }
·>}
·>

·>В случае шарпа тебе придётся завести пары методов downloadSomeData/downloadSomeDataAsync, download/downloadAsync и кучу копипасты.

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

Еще раз. витруальные потоки хороши для асинхронизации синхронного кода. Всё!

·>Зачем это всё?! Почему нельзя просто всегда писать "int res = task.Result"?
·>Сабж?

Затем, что мы останавливаем и поток для дожидания результата. Ведь он может выполняться значительно дольше чем код кода до task.Result.
task.Result это для поддержки старого синхронного кода. Вот где преимущество виртуальных потоков.