[whatwg] RFC: Alternatives to storage mutex for cookies and localStorage

Robert O'Callahan wrote:
> On Fri, Sep 4, 2009 at 9:44 PM, Jeremy Orlow <jorlow at chromium.org 
> <mailto:jorlow at chromium.org>> wrote:
>     I think it's pretty clear that the spec, as is, is not possible to
>     implement without making it trivial for a single website to lock up
>     all of your event loops....
> I don't think that's clear at all, yet.
> It's clearly *hard* to implement, and Chris' proposal for transactional 
> localStorage is a lot easier to implement, so if we can get away with 
> the compatibility break, we should.

I don't think it's hard to implement, even implementing it without 
literally using a global mutex.  I just don't think it solves the 
problem of guaranteeing cross-tab data integrity for poorly written 
sites.  And if the intention is to make scripts appear to run 
atomically, then I think there are better ways to specify that than 
storage mutex.

My problem with storage mutex boils down to the fact that by the letter 
of the spec, a script can lock out the UA indefinitely by just reading a 
cookie.  Obviously we're going to have to break that in some situations. 
  So if that's the case, why present that abstraction to scripts? 
Transactional semantics seems to be a better abstraction, and an 
ancillary benefit is that it's much easier to implement to boot.  Though 
even if it were harder to implement, I would still argue for it.


>     This is especially true if the storage mutex extends to cookies
>     since one tab running a poorly written site can lock everything up.
> Only if you actually implement the semantics using a single global lock. 
> I think we could do better.
> 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]

Received on Friday, 4 September 2009 15:22:09 UTC