FunctionPromise (was FunctionFuture)

NEW
Unassigned

Status

()

Core
DOM
5 years ago
7 months ago

People

(Reporter: dherman, Unassigned)

Tracking

Trunk
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [Shumway])

(Reporter)

Description

5 years ago
Here's a proposal for a new kind of object that will give programmers the ability to take a potentially large amount of source code and ask for it to be compiled asynchronously, in order to have more control over compile times. In particular, it allows an interactive application to provide temporary UI while code is being parsed and possibly compiled.

The proposal:

- a new kind of object called a FunctionFuture, which obeys the upcoming DOMFuture spec [1]

- the arguments to FunctionFuture are the same as the arguments to Function

- the fulfillment of a FunctionFuture is a Function that's constructed in the same way as `new Function` would have been

- the fulfilling of a FunctionFuture is done off the main thread; when the .then method is invoked, the Function must already be created

- a FunctionFuture can be copied to different workers:
* each worker sees a distinct Function object as the fulfilled result
* but internally, the actual work of compiling the Function can be done in one thread; the various threads can share the resulting internal compiled code (e.g. the results of AOT compiling an asm.js function)

- a FunctionFuture can be stored via IndexedDB:
* the arguments and body source are stored
* if the future is fulfilled, we also store any compiled code, along with cache validation information based on the browser version and cpuid
* when reading back the results, if the compiled code is still valid, the future can come back already fulfilled; otherwise it comes back unfulfilled -- whether the future comes back fulfilled is unspecified and left to the implementation

Rationale:

- It's built off of Function rather than (indirect) eval for several reasons:
* either Function or top-level indirect eval are equally powerful, so there's no loss of expressiveness
* but Function ensures there's no runtime execution required to construct it
* so the only errors are compile-time errors, meaning that there's no need to distinguish compile-time from runtime errors
* and sharing across workers means you want to defer execution to be done separately in each worker that touches the function; a Function makes the semantics of this straightforward
* it also makes it clear that the only actual significant work to do is compilation

- The use of futures allows for a single asynchronous interface for:
* the initial compilation of source
* extracting a function from offline storage, which may or may not require recompilation (and should therefore also be asynchronous)

- The use of futures will also make it possible to chain multiple async steps with the convenient semantics of .then

Dave

[1] https://github.com/slightlyoff/DOMFuture
(Reporter)

Comment 1

5 years ago
Two potential implementation challenges with this:

1. Implementing the Future semantics before we have a general-purpose implementation for the DOMFuture spec means we'll need to implement most of the .then semantics here. But in time that can be ripped out and replaced with a call to a general-purpose DOMFuture constructor. We can steal the logic from a popular Promises/A+ library like RSVP.js. [1]

2. Background compilation means it needs to be possible to always compile a Function on a background thread without it being linked directly to a global, so it can be linked to the global once a particular thread (main thread vs worker) calls .then. I don't know if that poses any problems in the current JS engine.

Dave

[1] https://github.com/tildeio/rsvp.js

Comment 2

5 years ago
Nice!  On first glance, I like these improvements/refinements of the original (misnamed :) idea; nice ergonomics for the presumably-common case but, IIUC, still full power to create and consume FunctionFutures from workers.
OS: Mac OS X → All
Hardware: x86 → All
Version: unspecified → Trunk

Updated

5 years ago
Depends on: 856410
One thing I've being missing in Function constructor is ability to create a named functions. It would be great if ` FunctionFuture` allowed creation of named functions not just anonymous ones.

Updated

4 years ago
Summary: FunctionFuture → FunctionPromise (was FunctionFuture)
This would fit in nicely with our plans for caching Shumway bytecode parsing and JIT compilation results.
Whiteboard: [Shumway]

Comment 5

3 years ago
For what it's worth, we would immediately consume this functionality if it were available.  :)

Comment 6

3 years ago
I still think this is a pretty good idea :)
Blocks: 1142562

Comment 7

a year ago
A year later, I still think this is a pretty good idea ;)
platform-rel: --- → ?
platform-rel: ? → ---
You need to log in before you can comment on or make changes to this bug.