Комментарии 5
сервер с абсолютно такой же логикой можно написать на С или С++ на 2-х (двух!) потоках и быть абсолютно уверенным что он использует только 2 потока не зависимо от количества клиентов и от заскоков компилятора. При этом решение будет абсолютно универсальным-переносимым на любую платформу, которая поддерживает соответственно С или С++ и потоки. А можно еще и сделать чтобы количество потоков точно определялось количеством ядер процессора после запуска программы-сервера. Кода будет не намного больше, вряд ли в 2 раза больше.
Универсальный переносимый сервер на двух потоках можно и на Rust написать.
Это мне кажется больше обучающая статья про async, поэтому некоторые примеры могут быть ходульные (что в целом распространённая проблема обучающих статей). Главное что показывает как async работает.
Универсальный переносимый сервер на двух потоках можно и на Rust написать.
Да, я не корректно выразился! У меня просто среды разработки под Rust нет. Универсальность, конечно, не в языке (Rust, С, С++, ...) который надо выбрать для реализации сервера, универсальность в том что потоки и сокеты это объекты системы и их поведение не зависит от языка (если конечно язык не ограничивает доступ к некоторым функциям этих объектов). А вот с asynch/await все намного сложнее так как это синтаксис или конструкции языка, и в разных языках они могут быть реализованы по разному, используют разные типы (классы) для оформления своей работы.
Если бы кто-то попробовал сравнить грамотную реализацию на потоках с реализацией через asynch/await это действительно было бы очень поучительно, только я боюсь не в пользу asynch/await.
сервер с абсолютно такой же логикой можно написать на С или С++ на 2-х (двух!) потоках и быть абсолютно уверенным что он использует только 2 потока не зависимо от количества клиентов и от заскоков компилятора.
А почему вообще "заскоки компилятора" попали в этот список?
Асинхронный Rust в трех частях. Часть третья: IO