и вот возникает у меня простой вопрос - будет быстрее работать вариант с корутинами или нет? что-то мне подсказывает, что те люди, которые с ходу ответят "быстрее" или "так же быстро" -- то им фиолетово, сколько будет стартовать поток, с какими настройками, как это внутри работает

у них возможно без потерь произошло преобразование кода из более запутанного в менее запутанный. для других вариантов использования, типа когда ты лично бережешь потоки, а-ля тредпул, чтобы экономить на их старте, свои точки синхронизации - там не вполне понятно, кто гарантирует или вообще понимает в мелочах, что это будет быстрее или вообще что будет сгенерено

да просто захотелось им ввести вот и ввели. нас же не заставляют на них молиться... в эмбедете без них жили и нормально все работало. все как писали конечные автоматы на массиве функций так и пишут. щас придут мол теперь массив не нужен то се... но имхо у меня вопросов сколько вызовет оверхеда код типа:
SM_TCP_IP[state](socket); не возникает от слова совсем
тогда как с коорутинами он как бы встает.

пусть поправят меня более опытные товарищи, но вроде плюсовые корутины делались из расчёта написания однопоточной программы

сможет ли компилятор раскрутить это - вопрос к компиляторщикам

Корутины в плане производительности и сложности отладки должны быть сопоставимы с коллбеками. Потоки к корутинам отношение имеют столь же косвенное, как и к коллбекам. Код разве что должен стать менее шумным

я не эксперт, но кажется, что самый цимус как раз в friendly awaiting on resource и этих всяких yield. и многопоточный код начинает выглядеть например как однопоточный. а однопоточный и так +- как однопоточный выглядит

Всяческие генераторы и стейтмашины однопоточны обычно, корутины в том числе и для них могут использоваться

Корутины и многопоточка - ортогональные вещи

ну как) я думаю, зависеть должно от того, в колбэках лямбды ли али нет. в первом случае непонятно имя функции, но понятна сигнатура, во втором и имя, и сигнатура зачастую прошиты явно. взять какой-нибудь openssl. Вы говорите, я так понимаю, о том, что "а теперь релаксируем знание о сигнатуре тоже" +- (разве там есть гарантии) и скажем, что будет сопоставимо.. информации, мне кажется, у меня еще меньше стало, чем было

а какой юз кейс у корутин в синхронном коде?

генераторы

ну не знаю. вот мы открываем http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p0912r5.html и окажется, что там указано про ограничения на потоки исполнения и про асинхронный код. Возможно, кто-то скажет, что "а давайте использовать в однопоточном коде" - добавлять асинхронщину в вызовах

Под сложностью отладки я в первую очередь имел ввиду понимание хода исполнения в рантайме. С коллбеками это сложно. С корутинами вряд ли станет лучше. Но зато код станет читаемее. О сигнатуре или явности описания мне нечего сказать — нужен практический опыт

тогда я ничего не понимаю, где проще стало

моё интуитивное понимание говорит, что корутины всё-таки про объектные потоки данных, но я могу ошибаться

Отдать длительную сетевую операцию на откуп системе, а самому продолжить работать в единственном потоке до получения ответа? А ещё, я видел интересный доклад, где асинхронные операции, например... позволяют префетчить данные из оперативной памяти в кэш процессора более эффективно — это всё однопоточный код

Не нужно множества вложенных лямбд-коллбеков, это ужасно вредит читаемости кода

Но это же многопоточный сценарий! Просто второй поток вы не порождали явно, но очевидно, что он есть.

спасибо за наводку