W3C home > Mailing lists > Public > whatwg@whatwg.org > September 2009

[whatwg] Application defined "locks"

From: Aaron Boodman <aa@google.com>
Date: Wed, 9 Sep 2009 11:08:02 -0700
Message-ID: <278fd46c0909091108j8738f57nbee28fe06f0a695b@mail.gmail.com>
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() {


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
Received on Wednesday, 9 September 2009 11:08:02 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:08:52 UTC