I think the canonical racy case is "the page wants to keep a counter for the number of times event X occurs" in a cookie or local storage.<div><br></div><div>It doesn't seem to be possible to achieve this without the mutex - the proposal below would break down if two pages tried to increment the cookie value simultaneously (if both pages changed "cookieValue=3" to "cookieValue=4" at the same time, the result of your merge step would likely be "cookieValue=4", not "cookieValue=5" as one might intend).</div>
<div><br></div><div>-atw<br><br><div class="gmail_quote">On Thu, Sep 3, 2009 at 1:08 PM, Benjamin Smedberg <span dir="ltr"><<a href="mailto:bsmedberg@mozilla.com">bsmedberg@mozilla.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On 9/1/09 7:31 PM, Jeremy Orlow wrote:<br>
<br>
> Does the silence mean that no one has any intention of implementing<br>
> this?  If so, maybe we should resign ourselves to a break in the single<br>
> threaded illusion for cookies.  This doesn't seem too outlandish<br>
> considering that web servers working with cookies will never have such a<br>
> guarantee and given that we have no evidence of widespread breakage with<br>
> IE 8 and Chrome.<br>
<br>
</div>We (Firefox) just started looking at this seriously: the implications of the<br>
global lock are pretty unpleasant.<br>
<br>
The major race condition appears to be code on the web that gets<br>
document.cookie, parses and modifies the string it to add or remove a<br>
particular cookie, and sets document.cookie again. This pattern could race<br>
against HTTP requests which also set cookies.<br>
<br>
Chris Jones proposed that we behave in a script-consistent manner without<br>
actually doing a global mutex:<br>
<br>
* When a script gets document.cookie, "check out" a consistent view of the<br>
cookie data. While the script runs to completion, its view of<br>
document.cookie does not change.<br>
* When the script sets document.cookie and runs to completion, calculate the<br>
delta with the original data and "commit" the changes.<br>
* HTTP Set-Cookie headers stomp on prior data at any time, but don't<br>
interfere with the consistent script view above.<br>
<br>
It would be nice to provide an web API to perform the operation of setting a<br>
cookie atomically, just as the Set-Cookie HTTP header does. That is:<br>
document.setCookie('foo=bar; domain=<a href="http://subd.example.com" target="_blank">subd.example.com</a>').<br>
<br>
It's not clear whether/how this same algorithm could be applied to<br>
localStorage, since the amount of data required to create a consistent state<br>
is potentially much larger. Is there an inherently racy API in .localStorage<br>
which we need to protect with complicate mutex/transactional schemes?<br>
<br>
--BDS<br>
</blockquote></div><br></div>