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
----
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