On Wed, Nov 25, 2009 at 6:20 AM, Ian Hickson <span dir="ltr"><<a href="mailto:ian@hixie.ch">ian@hixie.ch</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
On Wed, 4 Nov 2009, Rob Ennals wrote:<br>
><br>
> How about this for a solution for the localStorage mutex problem: [...]<br>
<br>
Here's a proposal based on the recent feedback:<br>
<br>
* There is a per-origin mutex. It can be owned by either an event loop<br>
task or a network layer task.<br>
<br>
* Things that wait until their task owns the storage mutex:<br>
- script fetching document.cookie<br>
- script setting document.cookie<br>
- script reading or writing a property of, or calling a method on, or<br>
enumerating the properties of, the localStorage object<br>
- the network layer setting cookies<br>
<br>
* Things that release the storage mutex if their task owns it:<br>
- the network layer after it has set cookies<br>
- script calling a method implemented in native code on a host object<br></blockquote><div><br></div><div>Is this a may or a must? As discussed, a may will result in different behaviors and strange bugs when someone develops on one browser and then tries to run their script on a different version of that browser or different browsers since they will probably have subtly different cases when they'll need to release the lock. If it's a must, then we'll take a small hit in all of our script binding code, but things will be more interoperable.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
- script setting document.domain<br>
- a task ending<br>
<br>
Reading or writing a property on a native object doesn't do it, so<br>
<br>
window['x'].document.forms['y'].value = 'foo';<br>
<br>
...doesn't release the mutex, though this (identical code) would:<br>
<br>
window['x'].document.forms.namedItem('y').value = 'foo';<br>
<br>
...because of namedItem() call.<br>
<br>
<br>
Is this unacceptable to anyone?<br>
<br>
Does anyone think that it would be better to enumerate a specific set of<br>
methods that reset the storage mutex instead? (i.e. the status quo)<br>
<br>
I am especially interested in opinions from browser vendors, and amongst<br>
those primarily those browser vendors actually implementing this now.<br></blockquote><div><br></div><div>On the rest of the questions, I don't have a strong opinion. Maybe Darin (the other Chromium guy who's deep in the trenches with this stuff) will.</div>
<div><br></div><div><br></div><div>-----------------------------</div><div><br></div><div><br></div><div>I know that we've discussed approximations of run to completion before, but maybe it's worth one more shot: What if on the first use of document.cookie or local storage we took a snapshot of both and used that during the task's execution. All writes would be queued up until the task finishes, at which point they'd be written to the central version of the cookie and/or local storage. This would provide a consistent view of data for the duration of the task and would solve almost all the atomicity problems except |document.cookie = document.cookie + "foo";|. For that, I'd suggest adding a method that allows scripts to do atomic modifications to storage within a callback.</div>
<div><br></div><div>I can understand everyone's desire to have completely serializable semantics for local storage access and cookies (if you don't count the servers' interaction with them), but maybe we need to go back to use cases. In a world with WebDatabase/WebSimpleDB, I really don't see anyone turning to LocalStorage except for more basic uses. Most of which I'm guessing need consistent reads much more than serialization of everything.</div>
<div><br></div><div>And let's be realistic. IE has had this problem with document.cookie for a long time. And IE8 now has this problem with localStorage. Given that in the best case (MS and all others implement the storage mutex) web developers will not be able to assume localStorage and document.cookie access is atomic for many years at a minimum, I think we're being pretty unrealistic about how much the storage mutex is going to improve anyone's life. Let's come up with an approximation, give developers a callback for atomic access, and be done with it.</div>
<div><br></div><div>J</div><div><br></div><div>P.S. Chrome is going to ship without locking, but since we auto-update all of our users, these problems won't necessarily persist for many years just because we shipped it.</div>
</div>