[whatwg] Application defined "locks"

On Wed, Sep 9, 2009 at 11:08 AM, Aaron Boodman <aa at google.com> wrote:

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

I wanted to leave it up to the app developer to choose the name so that they
could define how the lock is interpreted.

For example, they might want to partition the keyspace for local storage and
have separate locks for separate keys.  Or, they might want to have a single
lock that is inclusive of several storage mechanisms: LocalStorage and
FileAPI.

Besides, once we have an explicit locking API, why not just be generic and
give it a name divorced from LocalStorage or any kind of storage features
for that matter?  Locking can be useful to other applications that do not
even use local storage...



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

It is important to think of these differently from normal mutexes that you
might program with in C++.  Maybe I should have used the term "flag" instead
of "lock" ;-)

You might use a long lived lock to indicate that you are the instance
responsible for X.  I can imagine applications where there could be a master
/ slave relationships between the instances.  One instance is the master and
the rest are the slaves.

If we only had fine grained locking, then we are saying that we want
simulaneous instances of the same web app to be able to stop on each others
data in LocalStorage.  Instead, a web app developer might want to disable
LocalStorage features in all but the first instance of their web app.  The
problem is that your state is held not just in LocalStorage but also in JS
variables, the DOM, and perhaps in session state held by the server.  It is
easy for LocalStorage to get corrupted even with proper fine-grained
locking.  You still need a way to have a big "flag" that says... hey, i'm
the one messing with LocalStorage.  A good example is the browser's profile
directory.  Chrome and Firefox both only allow one instance of the app per
profile.  A long-lived lock is held to support such behavior.

I suspect there is some overlap with my proposal and shared workers.
 Perhaps what I am trying to accomplish here could even be implemented on
top of shared workers, although using shared workers to achieve mutual
exclusion locks seems rather heavyweight.

-Darin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090909/a680ff5a/attachment.htm>

Received on Wednesday, 9 September 2009 11:23:10 UTC