节点;Q 承诺延迟 [英] Node; Q Promise delay

问题描述

以下是一些基于我在 node 中运行的示例中注意到的行为的简单问题:

Here are some simple questions based on behaviour I noticed in the following example running in node:

Q('THING 1').then(console.log.bind(console));
console.log('THING 2');

这个输出是:

> "THING 2"
> "THING 1"

问题:

1) 为什么 Q 在对立即已知的值运行回调之前实现等待?为什么 Q 不够智能以允许第一行在第二行运行之前同步发出其输出?

Questions:

1) Why is Q implemented to wait before running the callback on a value that is immediately known? Why isn't Q smart enough to allow the first line to synchronously issue its output before the 2nd line runs?

2) "THING 2" 和 "THING 1" 输出之间的时间间隔是多少?是单个进程滴答声吗?

2) What is the time lapse between "THING 2" and "THING 1" being output? Is it a single process tick?

3) 深深包裹在 Promise 中的值是否存在性能问题?例如，Q(Q(Q("THING 1"))) 是否会异步等待 3 倍的时间才能完成，即使它可以有效地同步解析?

3) Could there be performance concerns with values that are deeply wrapped in promises? For example, does Q(Q(Q("THING 1"))) asynchronously wait 3 times as long to complete, even though it can be efficiently synchronously resolved?

推荐答案

这实际上是故意的.无论值是否已知，都要使其保持一致.这样就只有一个求值顺序，您可以依赖这样一个事实，即无论 Promise 是否已经结算，该顺序都是相同的.

This is actually done on purpose. It is to make it consistent whether or not the value is known or not. That way there is only one order of evaluation and you can depend on the fact that no matter if the promise has already settled or not, that order will be the same.

此外，如果不这样做，就可以编写代码来测试承诺是否已解决，并且根据设计，它不应该被知道和采取行动.

Also, doing it otherwise would make it possible to write a code to test if the promise has settled or not and by design it should not be known and acted upon.

这几乎就像做这样的回调风格的代码一样:

This is pretty much the as doing callback-style code like this:

function fun(args, callback) {

    if (!args) {
        process.nextTick(callback, 'error');
    }
    // ...
}

以便任何调用它的人:

fun(x, function (err) {
  // A
});
// B

可以确定 A 永远不会在 B 之前运行.

can be sure that A will never run before B.

请参阅 Promises/A+ 规范，then Method 部分，第 4 点:

See the Promises/A+ Specification, The then Method section, point 4:

onFulfilled 或 onRejected.

另见注释1:

这里的平台代码"是指引擎、环境和promise实现代码.在实践中，这个要求确保 onFulfilled 和 onRejected 异步执行，在调用 then 的事件循环之后，并使用新的堆栈.这可以通过宏任务"机制(例如 setTimeout 或 setImmediate)或微任务"机制(例如 MutationObserver 或 process.nextTick)来实现.由于promise实现被认为是平台代码，它本身可能包含一个任务调度队列或trampoline"，在其中调用处理程序.

Here "platform code" means engine, environment, and promise implementation code. In practice, this requirement ensures that onFulfilled and onRejected execute asynchronously, after the event loop turn in which then is called, and with a fresh stack. This can be implemented with either a "macro-task" mechanism such as setTimeout or setImmediate, or with a "micro-task" mechanism such as MutationObserver or process.nextTick. Since the promise implementation is considered platform code, it may itself contain a task-scheduling queue or "trampoline" in which the handlers are called.

所以这实际上是规范要求的.

So this is actually mandated by the spec.

广泛讨论以确保此要求明确 - 请参阅:

It was discussed extensively to make sure that this requirement is clear - see:

• https://github.com/promises-aplus/promises-spec/pull/70
• https://github.com/promises-aplus/promises-spec/pull/104
• https://github.com/promises-aplus/promises-spec/issues/100
• https://github.com/promises-aplus/promises-spec/issues/139
• https://github.com/promises-aplus/promises-spec/issues/229

这篇关于节点;Q 承诺延迟的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！