- From: Maciej Stachowiak <mjs@apple.com>
- Date: Wed, 25 Nov 2009 16:35:38 -0800
On Nov 25, 2009, at 7:46 AM, Jeremy Orlow wrote: > On Wed, Nov 25, 2009 at 6:20 AM, Ian Hickson <ian at hixie.ch> wrote: > On Wed, 4 Nov 2009, Rob Ennals wrote: > > > > How about this for a solution for the localStorage mutex problem: > [...] > > Here's a proposal based on the recent feedback: > > * There is a per-origin mutex. It can be owned by either an event loop > task or a network layer task. > > * Things that wait until their task owns the storage mutex: > - script fetching document.cookie > - script setting document.cookie > - script reading or writing a property of, or calling a method on, > or > enumerating the properties of, the localStorage object > - the network layer setting cookies > > * Things that release the storage mutex if their task owns it: > - the network layer after it has set cookies > - script calling a method implemented in native code on a host > object > > 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. Is there any observable difference between a "may" and a "must" (assuming the implementation has avoided deadlocks)? Dropping the mutex will just remove a guarantee, it won't force different behavior. You can still get lucky. Indeed, in a browser that only uses a single thread/process to render Web content, if you're not using workers you will always get lucky. Regards, Maciej -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20091125/184e7a8e/attachment.htm>
Received on Wednesday, 25 November 2009 16:35:38 UTC