The reason we sometimes need to release the storage mutex is to avoid
a deadlock that can occur if a thread holding the storage mutex for
domain X has to wait for another mutex Y - since whoever holds Y might
wait for X, creating a wait cycle. One way to avoid this problem is to
release the storage mutex if we need to wait for another mutex.
I'm not aware of any situation where a thread A would need to release
it's storage mutex due to actions by another process/thread B without
A using any API. It's fine for thread B to block waiting for another
domain's storage mutex so long as thread A isn't waiting for thread B
- which it can't be unless it uses an API.
Or to put it another way: if the thread can't call an API then it
can't block waiting for another storage mutex, thus deadlock can't
occur, thus we don't need to release the storage mutex.
Does that claify things? Or am I missing something?
-Rob
On Nov 4, 2009, at 2:21 PM, Mike Shaver <[email protected]> wrote:
On Wed, Nov 4, 2009 at 5:13 PM, Rob Ennals <[email protected]>
wrote:
How about this for a solution for the localStorage mutex problem:
"the user agent MAY release the storage mutex on *any* API
operation except
localStorage itself"
This guarantees that the common case of "several storage operations
in a row
with nothing in-between" works, but gives the implementors the
freedom to
release the storage mutex wherever else they find they need to.
How does it guarantee that? Can't the user agent release the mutex
due to activity in another process/thread, between operations that are
sequential in a given script?
Mike
