On Thu, Sep 10, 2009 at 6:37 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: 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>You mean when the browser implementation has a bug and fails to implicitly unlock?<br><br>Giving Web authors the crappy race-prone and deadlock-prone locking programming model scares *me*. 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. 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>
<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. Now, if we find that authors are needing to build explicit locks using localStorage, we should figure out their use-cases and see what a better solution for those use-cases might be, instead of giving them a more convenient way to endanger themselves.<br>
<br clear="all"></div></div>Rob<br>-- <br>"He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all." [Isaiah 53:5-6]<br>