W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2011

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

From: David Herman <dherman@mozilla.com>
Date: Mon, 3 Jan 2011 10:18:45 -0800
Cc: public-webapps@w3.org
Message-Id: <9A877460-2E79-4D63-B2B1-8D1752BEF4C1@mozilla.com>
To: Axel Rauschmayer <axel@rauschma.de>
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 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:42 GMT