W3C home > Mailing lists > Public > whatwg@whatwg.org > December 2007

[whatwg] Asynchronous database API feedback

From: Scott Hess <shess@google.com>
Date: Tue, 11 Dec 2007 15:14:28 -0800
Message-ID: <696e4b7c0712111514n403c6973w7ddc9c594c4a26eb@mail.gmail.com>
On Dec 11, 2007 3:02 PM, Oliver Hunt <oliver at apple.com> wrote:
> > It's clear that most people here feel passionately that this is the
> > wrong thing to do. Perhaps it's best that we table this until
> > something like workerpools are in the spec.
>
> Worker pools do not resolve the problem, even if you were to force
> any synchronous IO to be performed on a worker thread (where by force
> i mean attempting synchronous io on the main/ui thread would throw an
> exception or similar).  The problem is that once you have multiple
> threads, and those threads are unable to modify the DOM (allowing the
> DOM to be modified from a worker thread would cause too much havoc --
> there is much to much JS out there to allow JS to become
> multithreaded), so either you defer the synchronous IO into a async
> callback model to tell you when the io has completed -- you are now
> using the synchronous api to implement your own async api --

Exactly.  But the async API you're implementing is "Synchronize a
block of stuff from the server", rather than handling each individual
item asynchronously.  The synchronous synchronization code will likely
be an order of magnitude (or two) simpler to comprehend, which makes
verifying correctness much easier.  There just won't be so many places
for things to go wrong.

-scott
Received on Tuesday, 11 December 2007 15:14:28 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:08:38 UTC