Сообщение Re[23]: Можно ли избавиться от async|await? от 16.12.2025 18:04
Изменено 16.12.2025 18:11 novitk
Re[23]: Можно ли избавиться от async|await?
Здравствуйте, Serginio1, Вы писали:
S>Ну и чем это лучше
S>Task.WhenAll
а) WhenAll тут не нужен.
б) Суть в другом. В jvm nет никаких async функций. Любая функция может быть запущена, как синхронно, так и ассинхронно(виртуальные потоки, ака "зеленые"). Решение принимает тот, кто ее вызывает. При этом она, если она запущена на "зеленых", то блокировать реальные она не будет даже если там бесконечный цикл без всяких дотнетовских Task.Yield(). Сейчас прибежит mrTwister и скажет, что в GoLang то же. И отчасти он будет прав, но лишь отчасти. Из закриворукости "простоты" там не поддерживается вся семантика в обеих контестах. В частности, если функция вызвана через go, то ее результат получить невозможно. Единственный способ получения результата из ассинхронного вызова это использовать всякие неявные методы (обычно каналы, ну или shared memory), но это требует переписки функций, то есть фактически не сильно отличается от .net.
S>Ну и чем это лучше
S>Task.WhenAll
а) WhenAll тут не нужен.
б) Суть в другом. В jvm nет никаких async функций. Любая функция может быть запущена, как синхронно, так и ассинхронно(виртуальные потоки, ака "зеленые"). Решение принимает тот, кто ее вызывает. При этом она, если она запущена на "зеленых", то блокировать реальные она не будет даже если там бесконечный цикл без всяких дотнетовских Task.Yield(). Сейчас прибежит mrTwister и скажет, что в GoLang то же. И отчасти он будет прав, но лишь отчасти. Из за
Re[23]: Можно ли избавиться от async|await?
Здравствуйте, Serginio1, Вы писали:
S>Ну и чем это лучше
S>Task.WhenAll
а) WhenAll тут не нужен.
б) Суть в другом. В jvm nет никаких async функций. Любая функция может быть запущена, как синхронно, так и ассинхронно(виртуальные потоки, ака "зеленые"). Решение принимает тот, кто ее вызывает, a не тот кто пишет . При этом она, если она запущена на "зеленых", то блокировать она не будет даже если там бесконечный цикл без всяких дотнетовских Task.Yield(). Сейчас прибежит mrTwister и скажет, что в GoLang то же. И отчасти он будет прав, но лишь отчасти. Из закриворукости "простоты" там не поддерживается вся семантика в обеих контестах. В частности, если функция вызвана через go, то ее результат получить невозможно. Единственный способ получения результата из ассинхронного вызова это использовать всякие неявные методы (обычно каналы, ну или shared memory), но это требует переписки функций, то есть фактически не сильно отличается от .net.
S>Ну и чем это лучше
S>Task.WhenAll
а) WhenAll тут не нужен.
б) Суть в другом. В jvm nет никаких async функций. Любая функция может быть запущена, как синхронно, так и ассинхронно(виртуальные потоки, ака "зеленые"). Решение принимает тот, кто ее вызывает, a не тот кто пишет . При этом она, если она запущена на "зеленых", то блокировать она не будет даже если там бесконечный цикл без всяких дотнетовских Task.Yield(). Сейчас прибежит mrTwister и скажет, что в GoLang то же. И отчасти он будет прав, но лишь отчасти. Из за