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