On Fri, Oct 30, 2009 at 1:36 AM, Robert O'Callahan <span dir="ltr"><<a href="mailto:robert@ocallahan.org">robert@ocallahan.org</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Fri, Oct 30, 2009 at 7:27 PM, 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>You are right that the conditions are specific, but I don't know that that is the</div><div>exhaustive list. Rather than defining unlock points, I would implement implicit</div><div>
unlocking by having any nested attempt to acquire a lock cause the existing lock</div><div>to be dropped. Nesting can happen in the cases you mention, but depending on</div><div>the UA, it may happen for other reasons too.</div>
</div></blockquote></div><div><br>What reasons?<br><br>If these reasons are situations where it's fundamentally difficult, impossible, or non-performant to follow the spec, we should change the spec. Otherwise this would just be a bug in the UA.<br>
<br></div><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">For example, a JS library might evolve to use flash for something small (like<div>
storage or sound) that it previously didn't use when I first developed my code.</div>
<div>Voila, now my storage lock is released out from under me.</div></div></blockquote></div><div><br>This example still sounds overly contrived to me. Nevertheless, it seems strange to say that because there might be a few unexpected race conditions, you have decided to allow a much larger set of unexpected race conditions.</div>
</div></blockquote><div><br></div><div>I don't have a strong opinion either way on this one, but in general I'd say that making a race more subtle isn't usually much of a win.....especially when it comes to debugging it.</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 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>At this point, I'm not favoring implementing the storage mutex in Chrome. I</div>
<div>don't think we will have it in our initial implementation of LocalStorage. I think</div>
<div>web developers that care will have to find another way to manage locking, like</div><div>using a Web Database transaction or coordinating with a Shared Worker.</div></div></blockquote><br></div>Have you considered just not implementing LocalStorage? If it's so difficult for authors to use correctly and to implement according to the spec, this seems like the best path to me.<br>
</div></blockquote><div><br></div><div>We'd love to, but it's difficult given that most of the other vendors have already implemented it. I also believe that Microsoft's browser exhibits the same races that Darin's talking about. So I'm not really sure how you could suggest that us not implementing it is better than implementing the status quo.</div>
</div>