Futures (was: Request for JSON-LD API review)

Tab Atkins Jr. jackalmage at gmail.com
Fri Apr 19 15:50:52 PDT 2013

On Fri, Apr 19, 2013 at 3:35 PM, Kevin Gadd <kevin.gadd at gmail.com> wrote:
> My solution for cancellation has been to allow cancellation notifications to
> be bidirectional - that is, when you subscribe to completion notifications
> on a Future, you can also subscribe to cancellation notifications. Then it's
> possible to cancel a given future without breaking any other listeners (as
> long as they subscribed to cancellation notifications if they care about
> cancellation). Has that been considered? I can see how it might be too
> finicky for the average developer; losing out on cancellation really sucks
> though.
> In particular it feels more important to have explicit cancellation built
> into the object representing work if you can in JS, since there's no way to
> lean on the garbage collector to cancel work - in environments like Python
> you can make cancellation implicit by doing it when the Future representing
> the work is collected, but in JS that's impossible, so having an explicit
> way to dispose of a future is valuable, even if in many cases the
> cancellation doesn't do anything. It's also particularly good in terms of
> encapsulation - if there's a general cancellation mechanism that is
> well-factored, you can just universally make a habit of cancelling unneeded
> futures, and any backend implementations that support cancellation will
> automatically get told to cancel and save cycles/bandwidth. It means that
> you don't have to go add cancellation in 'after the fact' when the source of
> a Future changes from a local buffer to a network operation, or remove
> cancellation when you replace a network operation with a cache.
> Any kind of task scheduler like dherman's task.js can easily leverage this
> to automatically cancel any task represented by a cancelled Future, and in
> particular, task schedulers can propagate cancellation, by cancelling any of
> the Futures a task is waiting on when the task is cancelled. This has a very
> desirable property of allowing you to cancel a huge, amorphous blob of
> pending work when it becomes unnecessary by simply cancelling the root - for
> example in one application I worked on, we kicked off a task to represent
> each avatar in a 3D scene that was responsible for loading the avatar's
> textures, meshes, etc. If the user left the scene before the avatar was
> fully loaded, all we had to do was cancel the task and any pending texture
> loads or network requests automatically stopped. Getting that right by hand
> would have been much more difficult, and we wouldn't have necessarily known
> to build cancellation explicitly into that API when we started.

I'm curious about what sort of API you use for this.  Right now,
Futures are pretty easy to use, because there are only two useful
signals that a callback has to give - successful completion or error -
and it can do this by either returning or throwing.  It seems like
we've run out of basic syntax to use for this kind of message-passing,
though, and going any further would require a dedicated object.

Maybe this can just be done by a second argument that is given to the
callbacks, with a messaging object similar to the resolver object sent
to the resolver callback?

We could use this object to hold accept/reject/resolve functions too,
in case it's convenient to be more explicit about signaling these.
Then, though, we'd have to be careful to separate the semantics of
"functions that affect the output future" and "functions that talk to
the input future".


More information about the es-discuss mailing list