[whatwg] Application defined "locks"

[Darin Fisher]

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/66d7682c/attachment-0001.htm>