On Sat, Mar 28, 2009 at 11:29 AM, Michael Nordman <micha...@google.com>wrote:

> On Tue, Mar 24, 2009 at 2:11 AM, Ian Hickson <i...@hixie.ch> wrote:
>> On Fri, 20 Mar 2009, Jonas Sicking wrote:
>> > I do think it would be great if workers had access to some type of
>> > structured storage. However I agree that the fact that both the main
>> > thread and workers have synchronous access to the same storage is not
>> > acceptable since that means that we're violating the
>> > shared-nothing-message-passing design that makes workers not have to
>> > deal with locks and other traditional multithread hazards.
>> Agreed. The Database API seems well-suited for this, though.
> Again... its not just workers that are affected by this... speaking as
> someone
> that works on a multi-threaded browser, this is troubling. If its possible
> to
> spec features that allow script to poke at the world beyond the page
> boundaries in a fashion that doesn't not require locking semantics beyond

(I assume that "not" was unintended.)

> the scope of a single scriptable API call... that would be less troubling.

SQL storage where the single API call is "run this complex transaction"
might be acceptable.

But if the single API call is "access some shared state" and it's up to Web
developers to deal with locking and synchronization --- that will never be
acceptable. That burden must fall on browser developers, not Web developers.

"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah

Reply via email to