Re: [IndexedDB] Why rely on run-to-completion?

On Dec 29, 2010, at 2:44 PM, Axel Rauschmayer wrote:

> The pattern of assigning the success continuation after invoking the operation seems to be to closely tied to JavaScript’s current run-to-completion event handling. But what about future JavaScript environments, e.g. a multi-threaded Node.js with IndexedDB built in or Rhino with IndexedDB running in parallel? Wouldn’t a reliance on run-to-completion unnecessarily limit future developments?

As a long-time member of the ECMAScript standardization effort, I usually avoid making predictions about the future of JS, but I feel pretty confident predicting that the language is not going to evolve to support pre-emptive, shared-memory threading. See e.g. Brendan Eich's blog post from a few years ago:

    http://weblogs.mozillazine.org/roadmap/archives/2007/02/threads_suck.html

I don't think you need to worry about JS acquiring pre-emption semantics. We *are* working on standardizing generators, which are a sort of explicit pre-emption mechanism; in that case a programmer might write:

    var request = window.indexedDB.open(...);
    yield;                                        // relinquish control...
    request.onsuccess = function(event) { ... };  // oops, too late

but arguably that's not such a big deal since the programmer has explicitly done the assignment after yielding control.

All that said, I agree with you that the API design requiring the programmer to assign listeners mutably, rather than being able to use the more functional approach, is clunky.

Dave

Received on Monday, 3 January 2011 21:26:51 UTC