- From: Drew Wilson <atwilson@google.com>
- Date: Thu, 3 Sep 2009 15:19:09 -0700
On Thu, Sep 3, 2009 at 1:32 PM, Benjamin Smedberg <bsmedberg at mozilla.com>wrote: > On 9/3/09 4:24 PM, Drew Wilson wrote: > > 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. > > > > 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). > > Is that case important? I think that it's more important to make sure that > script doesn't inadvertently remove or modify cookies due to races in > document.cookie, but that maintaining a single-threaded view of the cookie > data is not desirable. > You're asking the wrong guy - I'm in the "don't bother trying to ensure consistency" camp :) I'm just parroting the arguments that were offered previously. If I hadn't lost the arguments about providing workers access to cookies, then I'd say that pages that care about cookie consistency should set cookies via a SharedWorker. But failing that, it seems like the choices are fairly stark: ensure consistency and take the performance hit in all multi-threaded browsers, or explicitly disavow consistency, and console ourselves by making our future APIs more multi-process friendly. I do understand the point of view of the "correctness over performance" camp - however, as Jeremy points out, it doesn't sound like those arguments have gotten much traction with actual implementors yet. > > --BDS > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090903/09f087a2/attachment.htm>
Received on Thursday, 3 September 2009 15:19:09 UTC