[whatwg] localStorage mutex - a solution?

[Rob Ennals]

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 <mike.shaver at gmail.com> wrote:

> On Wed, Nov 4, 2009 at 5:13 PM, Rob Ennals <rob.ennals at gmail.com>  
> 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