- From: Aaron Boodman <aa@google.com>
- Date: Wed, 9 Sep 2009 11:08:02 -0700
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
Received on Wednesday, 9 September 2009 11:08:02 UTC