When we had this discussion last, there was significant pushback on this - the argument was basically "we have no evidence that cookie-based race conditions *aren't* causing sporadic breakages", which is true. It's inherently difficult to measure.<div>
<br></div><div>As an aside, I'll note that the majority of pushback came from developers of platforms that were inherently single-threaded, and so enforcing synchronicity had no impact on the performance of their platforms. It's easy to be a purist when there's no cost.</div>
<div><br></div><div>Now that more browsers are moving to multi-process architectures and will soon be faced with having to reduce the performance of their platforms to enforce cookie coherence, I wonder if people's attitudes have changed. I, too, would be interested in hearing if the folks working on multi-process firefox are planning to implement this piece of the spec.</div>
<div><br></div><div>-atw<br><br><div class="gmail_quote">On Wed, Sep 2, 2009 at 9:55 AM, Darin Fisher <span dir="ltr"><<a href="mailto:darin@chromium.org">darin@chromium.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br><br><div class="gmail_quote"><div class="im">On Tue, Sep 1, 2009 at 4:31 PM, Jeremy Orlow <span dir="ltr"><<a href="mailto:jorlow@chromium.org" target="_blank">jorlow@chromium.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div></div><div>On Wed, Aug 26, 2009 at 3:24 PM, Jeremy Orlow <span dir="ltr"><<a href="mailto:jorlow@chromium.org" target="_blank">jorlow@chromium.org</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">
<div class="gmail_quote"><div>On Wed, Aug 26, 2009 at 3:05 PM, Robert O'Callahan <span dir="ltr"><<a href="mailto:robert@ocallahan.org" target="_blank">robert@ocallahan.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>On Wed, Aug 26, 2009 at 2:54 PM, Jeremy Orlow <span dir="ltr"><<a href="mailto:jorlow@chromium.org" target="_blank">jorlow@chromium.org</a>></span> wrote:<br></div><div class="gmail_quote"><div>
<blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">
<div class="gmail_quote">Is there any data (or any way to collect the data) on how much of the web IE and Chrome's current behavior has broken? Given that there hasn't been panic in the streets, I'm assuming approximately 0%?</div>
</blockquote></div><div><br>We previously had a lengthy discussion about this.<br><br>If a site has a cookie race that causes a problem in IE/Chrome one in every 10,000 page loads, are you comfortable with that?</div></div>
</blockquote><div><br></div></div><div>I'm much more comfortable with that than the cost of a global mutex that all cookies and LocalStorage share. There are other ways to come about this problem (like developer tools).</div>
<div><br></div><div>I'm pretty sure Chromium has no intention of implementing a global storage mutex and putting all cookie access under it. Has anyone heard anything (either way) from Microsoft? Are there any browsers moving to a multi-event-loop (be it multi-threaded or multi-process) based model that intend to implement this? If not, then it would seem like the spec is not grounded in reality.</div>
</div>
</blockquote></div><br></div></div><div>Does the silence mean that no one has any intention of implementing this? If so, maybe we should resign ourselves to a break in the single threaded illusion for cookies. This doesn't seem too outlandish considering that web servers working with cookies will never have such a guarantee and given that we have no evidence of widespread breakage with IE 8 and Chrome.</div>
</blockquote><div><br></div></div><div>IE 6 <-- it is also multi process. you can poke at wininet from any application and change the cookies for IE.</div><div><br></div><font color="#888888"><div>-darin</div></font><div class="im">
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>If we were to get rid of the storage mutex for cookie manipulation (as I believe we should) maybe we should re-examine it for local storage. At a minimum, it could be implemented as a per-origin mutex. But I feel strongly we should go further. Why not have an asynchronous mechanism for atomic updates? For example, if I wanted to write an ATM application, I would have to do the following:</div>
<div><br></div><div>var accountDelta = /* something */;</div><div>window.localStorage.executeAtomic(function() {</div><div> localStorage.accountBalance = localStorage.accountBalance + accountDelta;</div><div>}</div><div>
<br></div><div>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:</div><div><br></div><div>localStorage.accountBalance = localStorage.accountBalance + accountDelta; // It's atomic, so no worries!</div>
<div>var balance = localStorage.accountBalance; /* Oh no!!!! This isn't safe since it's implemented via multiple statements... */</div><div>localStorage.accountBalance = balance + accountDelta; /* ....we should have used localStorage.executeAtomic! */</div>
<div><br></div><div>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.</div>
<div><br></div><div>I know this is radical stuff, but the way things are speced currently just are not practical.</div><div><br>
</div><div>J</div>
</blockquote></div></div><br>
</blockquote></div><br></div>