[whatwg] Application defined "locks"

[Aaron Boodman]

On Wed, Sep 9, 2009 at 10:55 AM, Darin Fisher<darin at chromium.org> wrote:
> I imagine a simple lock API:
> window.acquireLock("name")
> window.releaseLock("name")

I do not think it is a good idea to allow long-lived (past a stack
frame) locks on the types of things we've been discussing (local
storage, databases, etc).

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

There would presumably have to be a separate name value for each API,
though, right? So we're talking about the difference between:

window.acquireLock("localStorage", function() {
...
});

and:

window.acquireLocalStorage(function() {
...
});

It doesn't seem like much of a win for reusability IMO.

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

Do you have an example of a place where we want to allow long-lived locks?

- a