Почему асинхронная функция работает иначе?

Question

[Aligatro]

Помогите в понимании асинхронных функций в js. Я накидал простенький пример в котором по непонятной мне причине async функции внутри которых loop с разным количеством итераций выполняются одновременно, а не по порядку (сначала там где итераций меньше, после там где больше).
Пример кода.

Для примера вот тот же самый код но реализованный через задержку используя setTimeout, который работает правильно - https://jsfiddle.net/jrk7p3tx/

Оставлю это объяснение будущему себе:
Любая функция вызванная в основном потоке, будь то синхронная или возвращающая промис, будет этот самый поток блокировать до окончания её выполнения. Единственное что доступно разработчику, это возможность зашафлить стек вызова (например обернув в setTimeout) в котором сначала будут выполнены функции из основного потока, а после те которые придут из очереди событий от setTimeout.

В итоге получается что результаты при использования loop'ов "появляются одновременно", потому-что всё это время идёт блокирующая обработка циклов в основном потоке.
Во втором же примере setTimeout откладывает отправку простого объекта (а не исполнение блокирующего кода) плюс таймер крутится не в основном потоке, а в параллельном (webAPI). Что в итоге даёт эффект неблокирующего параллельного поведения.

Answer 1

[0xD34F]

выполняются одновременно

Всё-таки не одновременно. Поток выполнения один, так что... [разводит руками]

Из-за чего у вас возникла иллюзия "одновременности" - вы результат работы синхронного кода (*) решили получать асинхронно. Вызвали первый раз showText - цикл открутился, замечательно, но демонстрации результата пока не происходит, потому что await. Вот когда поток выполнения освободиться, тогда да. А до того - надо второй вызов showText выполнить. Ну а когда вызовы showText отработают - вот тогда их результаты и показываются, сразу все.

* Вы можете возразить - ...

...ну как же так, у меня там промис используется. А так. Недостаточно написать new Promise, чтобы получить желаемую асинхронность. Проведите небольшой эксперимент - откройте консоль, выполните

console.log('щас будем создавать промис');
new Promise(r => {
  console.log('создаём промис');
  setTimeout(() => {
    console.log('так, сейчас дёрнем резолв');
    r();
    console.log('резолв дёрнули');
  });
}).then(() => console.log('зарезолвились, наконец-то'));
console.log('промис создан');

и посмотрите на порядок вывода сообщений. Потом то же самое ещё раз, но без оборачивания резолва в setTimeout. Подумайте. Подумав, можно будет сделать очевидный вывод: а промисы-то - синхронны (да-да, вот так), код внутри промисов выполняется сразу после вызова конструктора. Асинхронным является получение результата.

Comments

[Aligatro]

Большое спасибо за развернутый ответ и за то что пролили свет на ситуацию. Но в таком случае возникает вопрос, почему promisы от setTimeout выполняются последовательно при блокирующих awaitах (2 пример), причина в самой обёртке setTimeout?

[0xD34F]

Aligatro, не понимаю, что вам непонятно. Разверните свою мысль.

[Aligatro]

Ну смотрите, по идее, сам await является блокирующим и любой код после него должен исполнится только после обработки промиса await'ом.

Но в коде ниже, при использовании timeout, вызов функции с await внутри не блокирует поток, более того промисы обрабатываются в правильно порядке (сначала скрипты основного потока, потом асинхронная функция с задержкой в 1сек, после в 4).

// Исполняется после вызова лупа
let loopAsync = ms => new Promise(resolve => setTimeout(resolve, ms * 1000));

const getSomeTextAsync = async (text, time) =>
  `value - ${text} was showed with delay ${time} and while is ${await loopAsync(time)}`;

const showTextAsync = async (sometext, time) => {
	// блокирующий await
  sometext = await getSomeTextAsync(sometext, time);
  console.log(sometext);
}

// Основной поток
showTextAsync('something that works in async way', 4); // 1 вызов функции с блокирующим авейтом внутри
showTextAsync('something that works in async way', 1); // 2 вызов функции с  блокирующим авейтом внутри
console.log('something that work in main thread');

// console show
// something that work in main thread
// something that works in async way was showed with delay 1
// something that works in async way was showed with delay 4

[0xD34F]

Aligatro,

по идее, сам await является блокирующим

Ясно. В своей основе async/await имеют те же промисы, так что "блокирующее" действие await'а не распространяется за пределы той функции, где await использован. Перепишите свой код на промисах, и абсурдность ожидания "блокировки" потока выполнения при вызове showTextAsync станет очевидной.

[Aligatro]

0xD34F,
После препарирования call stack'а в консоли и повторного прочтения материала event'ам, картинка вроде сложилась.

Любая функция вызванная в основном потоке, будь то синхронная или возвращающая промис, будет этот самый поток блокировать до окончания её выполнения. Единственное что доступно разработчику, это возможность зашафлить стек вызова (например обернув в setTimeout) в котором сначала будут выполнены функции из основного потока, а после те которые придут из очереди событий от setTimeout.

В итоге получается что результаты при использования loop'ов "появляются одновременно", потому-что всё это время идёт блокирующая обработка циклов в основном потоке.
Во втором же примере setTimeout откладывает отправку простого объекта (а не исполнение блокирующего кода) плюс таймер крутится не в основном потоке, а в параллельном (webAPI). Что в итоге даёт эффект неблокирующего параллельного поведения.

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

Еще раз спасибо за подробное разъяснение.

Answer 2

[yarnstart]

Comments

[Aligatro]

С обёрткой они выполняются не блокируя основной поток, но всё равно вызов функции с большим количеством итераций отрабатывается раньше, а не наоборот.