Implementation options for ES2015 Promise support

[fatcerberus]

There are some interesting challenges for an Ecmascript engine to support Promises.

• First and foremost, settlement (fulfill/reject) must be be asynchronous: When a Promise is resolved, the handler is not called immediately but instead gets queued into what ES6 refers to as a Job Queue. To support this there must be an event loop of some kind. Duktape currently has no such thing.
• Promises in a promise chain are quite tightly linked such that the resolution of an earlier promise directly begins the process of resolving the next. A typical JavaScript implementation will make heavy use of closures to support this, a luxury C code doesn't have. Some kind of solution using internal properties is needed instead, which is awkward and if not done carefully could expand footprint unnecessarily.
• In contrast with exceptions thrown in synchronous code, what to do with uncaught promise rejections is not as obvious. Handlers need not be attached to a promise chain immediately and in fact could be added at any time before or after the promise is settled. Therefore it's not enough for the engine just to say, "Nobody will handle this rejection, ergo uncaught" and crash. Complicating matters further is that, if it turns out that no rejection handler is ever attached, all information about the error--or even that there was ever an error in the first place--will be lost. Indeed, because promise settlement is performed asynchronously and (nominally) in a separate execution environment, there is no way to handle an error thrown by a promise except in a rejection handler. Some potential solutions to this have been devised in third-party Promise implementations, e.g. Promise.prototype.done(), but these have their own issues and are sometimes controversial. For example bluebird heavily discourages use of .done(): http://bluebirdjs.com/docs/api/done.html

This issue is for discussion of the above challenges and the best options for solving them in a small-footprint engine such as Duktape.

[svaarala]

Fairness is a very difficult issue with job queues in general. As an initial implementation I'd probably want to go with a single FIFO which is at least easily understandable. It wouldn't be optimal for cases where jobs have concrete priorities, but a multi-queue model seems unnecessarily difficult as a first implementation.

For the concrete case with the debugger commands, I'm not sure if that's a practical concern? Assuming that the job queue would starve, why would a debug client issue a never ending debug command stream if one assumes no actual code (i.e. job entries) is executed? I'm not saying it's impossible, just that I'm not sure if it's a practical concern.

[svaarala]

But in case it's also a practical issue, maybe it would suffice to use a simple rate limiting mechanism to cap the rate of messages processed in a non-paused state. The executor already does this, only checking for debug messages once every 200ms or so (very roughly, and maybe I remember the exact millisecond number wrong :-), so it wouldn't be a major change in how the debugger works in a running state.

[svaarala]

As discussed above, I'm not entirely happy with the basic queue-job/process-job design because it needs application co-operation. In particular, if an application uses Promises but doesn't call duk_process_job() or whatever, Promises won't work and job queue will just grow without limit. It also won't be immediately obvious why things don't work.

So overall I can see four options:

• If you use Promimses, you must call duk_process_job() to handle resolved ones, and there's no control in place to detect if you don't call duk_process_job(). The control would essentially be documentation.
• Process job queue to completion every time when returning to an empty callstack. This would work in some cases, but: (1) it may not be nice to process the jobs right away in semi realtime applications, and (2) some applications never return to an empty callstack because there's a main() eventloop.
• There would be an explicit API call to enable job queue support, i.e. the application would indicate it supports job queue processing and will call duk_process_job(). Trying to queue any jobs or use Promises would throw errors if the API wasn't called. You could still just not process the pending jobs despite doing the API call, but at least it would be a clear application bug and existing code would cause clean error throws because it didn't support queue processing. A small variant of this approach is to add flags to heap creation, and add a DUK_HEAP_SUPPORT_JOBS.
• Job queue would be processed to completion when returning to an empty callstack by default, but an API call could be used to switch to manual processing via duk_process_job(). Same issues here as for option 2, e.g. some applications never return to an empty callstack.

[fatcerberus]

Does ES6 (or later) have anything to say about the engine's responsibility w.r.t. timing of job processing?

[svaarala]

I haven't read through it all in detail but I'd be surprised if it did, other than saying they should execute from an "empty call stack" (and maybe "without delay", though a requirement like that would necessarily be very vague). But I'll check that when I actually start work on the job queue.

[koush]

Hi all, been using duktape for a while in a home automation project. It provides a scripting environment to plugins for the system.

I currently have Promise support implemented via Babel polyfill: all that was necessary was an implementation of setTimeout/setImmediate. The duktape embedder needs to provide this in the global scope, and that becomes the job queue that has been discussed.

Babel also provides support for await/async and generators via transforms, in fact most (all?) of the recent ecmascript features work after transpile.

[MElkady]

@koush I'm trying to achieve the same thing, can you share your bable config? I can't get Promises & async/await polyfill-ed properly

[losper]

You can try bluebirdjs, but you need to implement your own setTimeout or process.nextTick.

Promise = require('bluebird'); 
Promise.setScheduler(function(fn) {
    process.nextTick(fn);
    //setTimeout(fn, 0);
});

[ThomasRogg]

In low.js (complete Node.JS implementation based on DukTape, especially for microcontrollers with less resources) I just implemented a complete Promise implementation in C with the DukTape API, see

https://github.com/neonious/lowjs/blob/master/src/low_promise.cpp

It has almost no additional dependencies, notably it uses low_call_next_tick, our native C implementation of process.nextTick.