[whatwg] Application defined "locks"

[Michael Nordman]

+1, a nice refactoring of the implied locking gunk in the storage api.

On Wed, Sep 9, 2009 at 10:55 AM, Darin Fisher <darin at chromium.org> 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 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/63c93ae6/attachment.htm>