<meta charset="utf-8">On Fri, Sep 11, 2009 at 11:52 AM, Darin Fisher <span dir="ltr"><<a href="mailto:darin@chromium.org">darin@chromium.org</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">

<div class="gmail_quote"><div><div class="h5"><div>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?)  </div></div></div>

</div></blockquote><div><br></div><div>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.</div><div><br>
</div>
<blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">

<div class="gmail_quote"><div>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.</div>

<div><br></div><div>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.</div>

</div></blockquote><div><br></div><div>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.</div>

<div><br></div><div>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.</div><div><br></div></div><br><div class="gmail_quote">On Fri, Sep 11, 2009 at 1:55 PM, James Robinson <span dir="ltr"><<a href="mailto:jamesr@google.com">jamesr@google.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div class="gmail_quote"><div>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?</div>

</div></blockquote><div><br></div><div>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.</div>

</div>