Комментарии 13
Интересно, но не знаю как это можно применить в моем случае, когда проекты очень легкие
для клиента всё верно
для сервера "Для сервера
Масштабируемость: вы освобождаете потоки,"
не верно
PS Я бы написал "Масштабируемость: вы не блокируете потоки". Это — точная (AFAIK)формулировка. И это — почти одно и то же, что и та, против которой вы возражаете.
А что не так?
Попробуйте отправить 10 млрд одинаковых HTTP-запросов:
С использованием асинхронных методов.
С использованием классических тредов.
Сравните использование CPU, потоки которого освобождаются от тонны переключений контекста.
А теперь добавьте в эти HTTP-запросы запросы к БД длительностью от 100мс, исправьте ошибки в многопоточности при использовании тредов и давайте тоже сравним время, затраченное на разработку и пропускную способность сервера. Время на разработку умножьте на рыночную ставку разработчика, умеющего "в треды".
Добавление io-потоков в asyncio приложение лишь усилит демонстрационный эффект превосходства подхода с асинхронным io.
Всё остальное не очень понял. Разработчика умеющего в треды, пока ещё, найти проще, чем разработчика умеющего в async/await.
У System.Linq.Async
есть неприятная особенность: если не предпринять дополнительных действий, передаваемые в него делегаты не выполняются на оригинальном контексте синхронизации.
"Про Стивена Клири можно сказать «он всерьез занялся многопоточным программированием еще до того, как это стало мейнстримом». "
его еще на свете не было, "как это стало мейнстримом"
Асинхронные потоки от Стивена Клири