[whatwg] Application defined "locks"

[Darin Fisher]

On Wed, Sep 9, 2009 at 3:37 PM, Maciej Stachowiak <mjs at apple.com> wrote:

>
> On Sep 9, 2009, at 10:55 AM, Darin Fisher wrote:
>
>  The recent discussion about the storage mutex for Cookies and LocalStorage
>> got me thinking....
>>
>> Perhaps instead of trying to build implicit locking into those features,
>> we should give web apps the tools to manage exclusive access to shared
>> resources.
>>
>
> I'm really hesitant to expose explicit locking to the Web platform. Mutexes
> are incredibly hard to program with correctly, and we will surely end up
> with stuck locks, race conditions, livelocks, and so forth. For Workers I
> was happy that we managed to avoid any locking primitives by using a
> message-passing model, but explicit mutexes would ruin that.
>
>  - Maciej
>
>

Note: I probably made a mistake calling these locks since they do not work
like normal mutexes.  You can only wait for one of these locks
asynchronously.  There is no synchronous blocking, which avoids most of the
problems you mention.  Also, the locks are cleared when the page is
destroyed or navigated to another domain, so you lose the problem of stuck
locks.

What motivated this was that I wanted the ability to simulate the database
transaction model.  Since we support that, we might as well support a
similar system that is independent of a particular storage mechanism.  Seems
reasonable to me.

Alternatively, if we had a way to set a value in local storage and read the
value that was there, then a web page could implement a "flag" to indicate
mutual exclusion. Someone interested in acquiring a flag could wait for a
storage event to indicate that the flag was cleared.  However, what is
missing is that there isn't a way for the "flag" to be auto-cleared when the
DOM window is closed or navigated to another domain.

-Darin



>
>
>> ----
>>
>> I imagine a simple lock API:
>>
>> window.acquireLock("name")
>> window.releaseLock("name")
>>
>> acquireLock works like pthread_mutex_trylock in that it is non-blocking.
>>  it returns true if you succeeded in acquiring the lock, else it returns
>> false.  releaseLock does as its name suggests: releases the lock so that
>> others may acquire it.
>>
>> Any locks acquired would be automatically released when the DOM window is
>> destroyed or navigated cross origin.  This API could also be supported by
>> workers.
>>
>> The name parameter is scoped to the origin of the page.  So, this locking
>> API only works between pages in the same origin.
>>
>> ----
>>
>> We could also extend acquireLock to support an asynchronous callback when
>> the lock becomes available:
>>
>> window.acquireLock("name", function() { /* lock acquired */ });
>>
>> If the callback function is given, then upon lock acquisition, the
>> callback function would be invoked.  In this case, the return value of
>> acquireLock is true if the function was invoked or false if the function
>> will be invoked once the lock can be acquired.
>>
>> ----
>>
>> Finally, there could be a helper for scoping lock acquisition:
>>
>> window.acquireScopedLock("name", function() { /* lock acquired for this
>> scope only */ });
>>
>> ----
>>
>> This lock API would provide developers with the ability to indicate that
>> their instance of the web app is the only one that should play with
>> LocalStorage.  Other instances could then know that they don't have
>> exclusive access and could take appropriate action.
>>
>> This API seems like it could be used to allow LocalStorage to be usable
>> from workers.  Also, as we start developing other means of local storage
>> (File APIs), it seems like having to again invent a reasonable implicit
>> locking system will be a pain.  Perhaps it would just be better to develop
>> something explicit that application developers can use independent of the
>> local storage mechanism :-)
>>
>> ----
>>
>> It may be the case that we want to only provide acquireScopedLock (or
>> something like it) to enforce fine grained locking, but I think that would
>> only force people to implement long-lived locks by setting a field in
>> LocalStorage.  That would then result in the locks not being managed by the
>> UA, which means that they cannot be reliably cleaned up when the page
>> closes.  I think it is very important that we provide facilities to guide
>> people away from building such ad-hoc locks on top of LocalStorage.  This is
>> why I like the explicit (non-blocking!) acquireLock and releaseLock methods.
>>
>> -Darin
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090909/3527975a/attachment-0002.htm>