<div class="gmail_quote">On Wed, Sep 9, 2009 at 4:24 PM, Robert O'Callahan <span dir="ltr"><<a href="mailto:robert@ocallahan.org">robert@ocallahan.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Thu, Sep 10, 2009 at 6:37 AM, Darin Fisher <span dir="ltr"><<a href="mailto:darin@chromium.org" target="_blank">darin@chromium.org</a>></span> wrote:<br></div><div class="gmail_quote"><div class="im">
<blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">
<div class="gmail_quote"><div><div></div>Yes, exactly. Sorry for not making this clear.  I believe implicit locking for LocalStorage (and the implicit unlocking) is going to yield something very confusing and hard to implement well.  The potential for dead locks when you fail to implicitly unlock properly scares me</div>

</div></blockquote><div> </div></div><div>You mean when the browser implementation has a bug and fails to implicitly unlock?<br></div></div></blockquote><div><br></div><div>What concerns me are the cases where synchronous events (e.g., resizing an iframe) can cause script to execute in another domain.  As spec'd, there is a potential dead lock with the storage mutex.  We must carefully unlock in situations like this.  However, such unlocking will appear quite mysterious to users, so much so that I question the value of the implicit storage mutex.</div>
<div><br></div><div>That led me down this path of imagining a more explicit locking mechanism that would give the app control over how local storage is protected.</div><div><br></div><div>I agree that explicit locking can be a big dangerous hammer, but that's why I tried to soften it by removing blocking behavior.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="gmail_quote"><div><br>Giving Web authors the crappy race-prone and deadlock-prone locking programming model scares *me*.</div>
</div></blockquote><div><br></div><div>Me too.  I don't believe that I'm proposing such an API. </div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="gmail_quote"><div> Yes, your acquireLock can't get you into a hard deadlock, strictly speaking, but you can still effectively deadlock your application by waiting for a lock to become available that never can.</div>
</div></blockquote><div><br></div><div>Sure, but at least the thread of execution isn't blocked, and the user can recover by closing the tab or what have you.  By the way, you can already pretty much create my acquireLock / releaseLock API on top of SharedWorkers today, but in a slightly crappier way.  Are SharedWorkers problematic because of this?  I don't think so.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="gmail_quote"><div> Also, how many authors will forget to test the result of acquireLock (because they're used to other locking APIs that block) and find that things are OK in their testing?<br>
</div></div></blockquote><div><br></div><div>Perhaps the API could be different.  Perhaps the name "lock" is part of the problem.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="gmail_quote"><div>
<br>I think we should be willing to accept a very high implementation burden on browser vendors in exchange for minimizing the burden on Web authors.</div></div></blockquote><div><br></div><div>Yes, I wholeheartedly agree.  Note: my concern is that there is no good implementation for the storage mutex.  Implicitly dropping it at weird times is not a good answer.</div>
<div><br></div><div>-Darin</div></div>