[whatwg] Storage mutex and cookies can lead to browser deadlock
Robert O'Callahan
robert at ocallahan.org
Tue Sep 1 18:48:11 PDT 2009
On Wed, Sep 2, 2009 at 11:31 AM, Jeremy Orlow <jorlow at chromium.org> wrote:
> Does the silence mean that no one has any intention of implementing this?
>
I'm silent because I'm not currently working on this stuff so I can't say
what our plans are. But I'll be upset if I find out our plans are to break
the single-threaded model.
Alternatively, we could make it so that each statement is atomic, but that
> you have to use such a mechanism for anything more complicated. For example:
>
> localStorage.accountBalance = localStorage.accountBalance + accountDelta;
> // It's atomic, so no worries!
> var balance = localStorage.accountBalance; /* Oh no!!!! This isn't safe
> since it's implemented via multiple statements... */
> localStorage.accountBalance = balance + accountDelta; /* ....we should
> have used localStorage.executeAtomic! */
>
> Such ideas would definitely lighten lock contention and possibly eliminate
> the need for yieldForStorageUpdates (formerly getStorageUpdates). Another
> major bonus is that it'd allow us to expose localStorage to workers again,
> which is one of the top complaints I've gotten when talking to web
> developers about localStorage.
>
>
Making what should be (and always have been) meaning-preserving
transformations like splitting one JS statement into two no longer
meaning-preserving --- and in a non-testable way, to boot --- seems like a
pretty bad idea to me.
I know this is radical stuff, but the way things are speced currently just
> are not practical.
>
I think that expecting Web developers to reason about concurrency and race
conditions is not practical.
Rob
--
"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
53:5-6]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090902/045e3f6d/attachment.htm>
More information about the whatwg
mailing list