async/await

[ex0_planet]

Подумалось внезапно - а в какой момент и почему так получилось, что практически все современные языки пришли к промисам и сабжу для записи параллельного кода? До этого момента какие только извращения не бытовали: конечные автоматы, файберы, green threads (включая чудо нанотехнологий поверх duff device под названием protothreads), просто ад

Comments

[mbr]

Ну да. Нюанс в том, что даже для FSM нужны async/wait.

[ex0_planet]

Нет, зачем. Для

switch(state) {
case 0: do_this(); nextstate = 1; break;
case 1: do_that(); nextstate = 2; break;
....
}
return nextstate;

никакие дополнительные возможности не нужны, наоборот, поверх этого можно реализовать всё что угодно. Только неудобно.

[mbr]

это в идеальном мире. В реальности плодить дополнительные состояния ради гарантированно быстрых ответов от другого процесса смысла нет, проще и подождать.

[ex0_planet]

Тогда придется "плодить" вытесняющую многозадачность.

[mbr]

не обязательно.

[ex0_planet]

Не обязательно что? Либо вытесняться, либо уступать, какой третий вариант-то? "Можно подождать" это, извини, подмена задачи - хотя бы потому, что неизвестно сколько придётся ждать внешнего события к примеру.

[mbr]

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

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

[ex0_planet]

Разумеется не получишь потому что это у тебя cpu-bound задача. Асинхронность хорошо расшивает io-bound, это с самого начала было понятно.

[ext_122116]

Проблема с "чистыми" конечными автоматами в том, что у них очень быстро растет число состояний (механически объединяя два КА с количеством состояний m и n, мы получим КА с количеством состояний mn). То есть можно представить себе красивую и изящную КА-реализацию, скажем, несложного сетевого стека - но когда в реальной программе нам понадобится не только кидать пакетики по сети, но и мигать лампочкой - от красоты и изящества следа не останется.

[ex0_planet]

Только если автоматы вложенные или зависят друг от друга. К примеру в сетевой стек, описываемый автоматом с M состояниями надо добавить алгоритм, не знаю, congestion control какой-нибудь, который тоже автомат с N состояниями - вот там да, MxN в полный рост.

А с лампочкой и стеком это как раз контрпример :) там будет M+N состояний, причём независимых:

update_stack(m_state);
update_led(n_state);
update_input(k_state);
....

как это в 90% реальных систем и работает, собсно. Другое что переписать какой-нибудь нетривиальный алгоритм в виде стейт-машины - процесс КРАЙНЕ подверженный ошибкам.