[whatwg] Application defined "locks"

[Jeremy Orlow]

On Fri, Sep 11, 2009 at 11:52 AM, Darin Fisher <darin at chromium.org> wrote:

> Also, the other motivating factor for me is access to LocalStorage from
> workers.  (I know it has been removed from the spec, but that is
> unfortunate, no?)
>

This was only done because the storage mutex was added in.  Now that we're
closing in on ways to abolish the storage mutex, I think this concern may
soon go away.

 By definition, workers are designed to be long lived, possibly doing long
> stretches of computation, and being able to intermix reads and writes to
> storage during that stretch of computation would be nice.
>
> Moreover, it would be nice if a worker in domain A could effectively "lock"
> part of the storage so that the portion of the app running on the main
> thread could continue accessing the other parts of storage associated with
> domain A.  The implicit storage mutex doesn't support this use case very
> well.  You end up having to call the getStorageUpdates function periodically
> (releasing the lock in the middle of computation!!).  That kind of thing is
> really scary and hard to get right.  I cringe whenever I see someone
> unlocking, calling out to foreign code, and then re-acquiring the lock.
>  Why?  because it means that existing variables, stack based or otherwise,
> that were previously consistent may have become inconsistent with global
> data in storage due to having released the lock.  getStorageUpdates is
> dangerous.  it is a big hammer that doesn't really fit the bill.
>

To be honest, letting users pick how to lock things like this sounds VERY
scary to me.  If the intention is to split localStorage into multiple
domains, I think we should do just that.  For example, we could add
|window.getLocalStorage(name)| that would create a new object that
implements the storage interface.  |window.localStorage| could be an alias
to |window.getLocalStorage(null)| maybe?  We could then specify that you can
only hold a lock on one storage interface at once.

This is not a fully fleshed out idea, but I think it'd be FAR less dangerous
(and more intuitive) than giving raw access to locks.


On Fri, Sep 11, 2009 at 1:55 PM, James Robinson <jamesr at google.com> wrote:
>
> Is it really too late for DB and localStorage?  I'm still trying to get
> used to the standards process used here but I thought the idea with UAs
> implementing draft specs is that the feedback from the experience can be
> used to refine the spec - a few UAs have implemented synchronous access to a
> single resource from multiple threads and it appears to be problematic.
>  Wouldn't that mean it's a good time to revise the problematic parts?
>

In theory.  In practice, once a vendor has shipped something, it's somewhat
sacred.  Once multiple have, it's even more so.  This is somewhat
unfortunate, in my opinion, since very few people are using localStorage or
DB yet, but it's now very difficult to correct even major problems in the
spec.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090911/ec3ddc03/attachment-0002.htm>