Promise/Future: asynchrony in 'then'

Domenic Denicola domenic at domenicdenicola.com
Tue Apr 30 09:57:32 PDT 2013


This is actually up for clarification in the upcoming 1.1 version of the spec. The important invariant is that the function execution stack be empty of user code at the time `onFulfilled` and `onRejected` are called. The current phrasing does not suffice for this, as pointed out in

https://github.com/promises-aplus/promises-spec/issues/100

The current phrasing is just an (insufficient) means of working around the fact that JS doesn't specify an event loop; an attempt at being clever.

Discussion is ongoing at https://github.com/promises-aplus/promises-spec/pull/104

We seem to be converging around something more like the invariant I spoke of above, as prompted by Mark Miller; e.g. "`onFulfilled` or `onRejected` must not be called when the stack contains any user code." But this requires defining user code, which is tricky---it includes `[native code]`, but also base code from the platform (e.g. Node.js's built-in modules), and parts of the promise implementation itself (e.g. the internal trampolines used by Q and when among others, or the setImmediate polyfill many fall back on).


More information about the es-discuss mailing list