That's a good point. I can imagine that this could get particularly noisy if you use a library which decides to use localStorage itself, and so you aren't aware that localStorage has been used previously elsewhere.
One simple fix to avoid these warnings would be to introduce two functions, startAtomic and endAtomic, that a user uses to explicitly declare what they think is atomic. startAtomic declares that you are starting an atomic localStorage section, and returns a token. endAtomic declares that you are ending an atomic localStorage section, and takes the token as an argument. All localStorage that isn't between startAtomic and endAtomic is assumed to be part of the same atomic transaction. The only reason to use startAtomic and endAtomic is to suppress warnings by making it clear that things are *intended* to be part of different atomic blocks. They would typically be used only in libraries, and not by a user's own code. This is kind of ugly, but maybe everything else is uglier. All in all, I don't think there is a "good" solution to this problem. The challenge is arguably to find the solution which is "least bad". So far we have the following proposals: * Storage mutex, held until thread ends : browser vendors say they can't implement it * No storage mutex : can't implement important idioms such as test and set or increment * Specify when released : can't agree on what the set is, list gets confusing, may be called by libraries * Release on any API call : this proposal. It's ugly, but perhaps less ugly than everything else. -Rob On Tue, Nov 24, 2009 at 4:44 PM, Mike Shaver <mike.sha...@gmail.com> wrote: > On Tue, Nov 24, 2009 at 6:12 PM, Rob Ennals <rob.enn...@gmail.com> wrote: >> If you run your browser in "super-warnings-enabled" mode then you >> could have it warn you if you did anything remotely suspect between >> calls to localStorage (e.g. calling a function defined by an external >> javascript file or calling an API). > > How would the browser distinguish between > > storage-operation-1 > inadvertent-API-call > storage-operation-2-that-should-be-atomic-with-1 > > and > > storage-operation-1 > API-calls-to-gather-data-for-another-transaction > storage-operation-2-that-is-unrelated-to-1 > > ? Seems like that's a necessary distinction if it's not to just warn > all over the place uselessly! > > Mike >
