Обещает ли Promise.resolve(1); использовать очередь микрозадач?

Попробуйте -> Promise.resolve('there').then(r => console.info(r)); console.info('hello') Обратите внимание, как здесь написано hellothere. Само создание промиса не ставится в очередь, но обратные вызовы then выполняются во время опустошения очереди микрозадач перед следующим циклом событий.

Если в приведенном выше примере вы добавите setTimeout(() => console.info('everyone')); в начало, вы увидите, как теперь написано hellothereeveryone, это потому, что вместо этого тайм-аут будет использовать очередь макрозадач, и она имеет более низкий приоритет, чем микрозадача, и обрабатывается во время следующего события. петля.

IOW: Promise.resolve(1); действительно не включает никаких микрозадач, он становится актуальным везде, где у вас есть then обратные вызовы, и именно при обработке очереди микрозадач. Обратите внимание, что, возможно, стоит отметить, что обработка очереди микрозадач на самом деле sync, а не async, даже если кажется, что это async..

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

@trincot Может быть, какое слово вы бы предложили вместо этого? По сути, я просто указываю на то, что очередь не обрабатывается асинхронно, IOW: вы даже можете заблокировать свой браузер, если вы связали обещания в цепочку без каких-либо реальных async операций между ними.

Насколько я понимаю, в мире JavaScript термин асинхронный применяется всякий раз, когда функция выполняется/возобновляется движком при обработке очереди заданий, независимо от того, какая очередь заданий. Если ваша точка зрения заключается в том, что приоритет очереди микрозадач выше, чем у событий пользовательского интерфейса, то я бы сказал именно так.

@aLearner, похоже, процитировав спецификации, вы ответили на свой вопрос.

Для меня @trincot async — это основной event цикл, микрозадачи выполняются перед следующим циклом событий. Если в спецификациях указано, что обработка очереди microtask классифицируется как async, то пусть будет так. Но лично я не думаю, что это имеет какой-либо смысл.

Хотя для меня это имеет большой смысл.

@trincot const delay = () => {const t = Date.now()+1000; while (Date.now() < t);}; for (let l = 0; l < 10; l ++) { Promise.resolve().then(r => delay()) } Это заблокирует браузер на 10 секунд, если обработка очереди микрозадач была async это должно было заблокировать его только на 1 секунду 10 раз. например. использование setTimeout с l*1000 действительно сделает это. Так что для меня это различие — нечто большее, чем просто приоритет. И независимо от терминологии именно это я и пытался донести.

Конечно, я понимаю вашу точку зрения. Это звучит так запутанно, что у вас другое понятие асинхронности.

@trincot Для меня, если что-то есть async, то это то, что позволяет продолжать цикл событий основного потока, это было в случае, когда я писал код на C и мне приходилось возиться с PeekMessage / Postmessage и т. д. В Javascript есть такие вещи, как fetch / setTimeout и т. д., которые, по моему мнению, являются async, и не блокируют основной цикл событий. И именно поэтому я хотел подчеркнуть, что setTimeout(fn) не будет работать так же, как Promise.resolve().then(). Лучший пример -> shorturl.at/hnj6R

Как я уже написал, я понимаю вашу точку зрения. Вы просто используете другую концепцию «асинхронности» и связываете ее с блокировкой пользовательского интерфейса. Для меня это другое понятие. На ваш взгляд, обратный вызов then может выполняться синхронно. Но в сообществе JavaScript обычно используется слово «асинхронный», обратный вызов then всегда выполняется асинхронно. Посмотрите, например, как слово асинхронный используется в пункте 3.1 спецификации Promises/A+.

Я думаю, что Кит хочет здесь отметить, что .then() является асинхронным, но ВНУТРИ очереди микрозадач САМ синхронизируется. Я ошибаюсь?

@trincot В этой версии 3.1 вы заметили -> Since the promise implementation is considered platform code, it may itself contain a task-scheduling queue or “trampoline” in which the handlers are called. Техника setTimeout уже давно не используется в браузерах. В некоторых отношениях if — это просто -> const q = [() => console.info('one'),() => console.info('two')]; for (const fn of q) fn();, который запускается перед следующим тиком. Единственное отличие состоит в том, что очередь очищается браузером. Таким образом, вы бы не классифицировали этот фрагмент кода как async?

@trincot, возможно, проблема здесь в том, что вы считаете разумным кодом async и что современные браузеры делают с обещаниями. Насколько я понимаю, код async вообще не использовался в реализации Promise в современных браузерах. В большинстве случаев различие не имеет значения, в конце концов, зачем создавать обещание ни для одного async кода. Но, как я уже говорил, если у вас есть условные обещания, что когда-нибудь вы будете выполнять настоящий async, а иногда и чистый sync код, существует вероятность блокировки браузера или цикла событий узла. Со мной такое уже случалось, и это причина предупреждения.

@Keith Определение «асинхронного» заключается в том, что код выполняется вне обычного потока программы после того, как вызванная функция уже вернулась. Это касается как микрозадач, так и макрозадач.

Я хочу сказать, что там говорится, что вызовы then асинхронны. Всегда. В нем упоминается микрозадача как реализация, но это не меняет концепции асинхронности. Ключевые слова — «свежий стек». Я понимаю, что вы говорите, но вы постоянно используете слово «асинхронный» не так, как я считаю стандартным (например, в реализации Promises/A+).

@trincot Тогда я возвращаюсь к своему первоначальному вопросу: какую терминологию вы бы использовали для обозначения блокирующего характера опустошения очереди микрозадач? Для меня sync/async кажется таким логичным, что слив очереди событий использует выполнение synchronous. На самом деле я мог бы только что ответить на свой вопрос... Что я должен был сказать: blocking, это помогает.?

Да, вы имеете в виду «блокировку» событий пользовательского интерфейса. Это другая концепция. Но помните, что даже если вы отправляете обратный вызов в очередь с более низким приоритетом, как в случае с setTimeout, вы также блокируете пользовательские события во время выполнения кода JavaScript. Разница в том, что события с более низким приоритетом могут быть обслужены до того, как этот код начнет выполняться. Но как только это произойдет, оно также блокируется.

@Bergi Asynchronous computing is a paradigm where a user doesn't expect a workload to be executed immediately. Instead, the workload is scheduled for execution in the near future without blocking the application's latency-critical path Для меня критический путь приложения, который я бы предположил, - это цикл событий. И оно блокирует его. В любом случае, я думаю, что высказал свою точку зрения, и если терминология в JS соответствует сказанному, то это достаточно справедливо.

Нет, это не «неопределенно». Он инициализируется пустым списком в конструкторе, поэтому цикл по этому списку просто ничего не делает.

Но почему оно попадет в 27.2.3.1 Promise ( executor )? Я использую Promise.resolve(1), как указано в моей первоначальной задаче, поэтому он должен перейти к 27.2.4.7 Promise.resolve ( x ), в соответствии с которым выполняется следующий оператор 4. Set promise.[[PromiseFulfillReactions]] to undefined?

Он попадает в конструктор обещаний во время NewPromiseCapability(C). Обратите внимание, что promise.[[PromiseFulfillReactions]] = undefined происходит только после «Let reactions be promise.[[PromiseFulfillReactions]]», который представляет собой пустой список, передаваемый TriggerPromiseReactions.