On Nov 25, 2009, at 7:46 AM, Jeremy Orlow wrote:
On Wed, Nov 25, 2009 at 6:20 AM, Ian Hickson <[email protected]> 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
