<div class="gmail_quote">On Mon, Nov 2, 2009 at 1:28 AM, 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 Sun, Nov 1, 2009 at 3:53 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>On Fri, Oct 30, 2009 at 1:36 AM, Robert O'Callahan <span dir="ltr"><<a href="mailto:robert@ocallahan.org" target="_blank">robert@ocallahan.org</a>></span> wrote:<br></div><div class="gmail_quote">
<div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">
<div>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>
<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>
</div></div></blockquote><div><br></div></div><div>My point is that it is difficult to ensure that all situations where nesting can occur are understood apriori and that the list doesn't change over time. Because we are talking about multi-threading synchronization in a very complex system, I would much prefer a more isolated and less fragile solution.</div>
<div><br></div><div>Unlock if yieldForStorageUpdates is called.</div><div>Unlock when returning from script execution.</div><div>Unlock if another attempt to lock occurs (any form of nesting).</div><div><br></div><div>In the third case, I'd probably log something to the JS console to alert developers.</div>
<div><br></div><div>I believe this simple implementation covers most of the cases enumerated in the spec, and it has the property of being easier to reason about and easier to support (more future proof).</div></div></blockquote>
</div><div><br>I think this would make the spec too dependent on implementation details. If your implementation needlessly or accidentally "nests" script execution --- e.g. by firing an event synchronously that should be, or could be, asynchronous --- then you'd still conform to your spec while the behaviour you present to authors gets quietly worse.<br>
<br>If your description is (or can be, after suitable modifications) equivalent to what the spec currently says, but the equivalence is subtle (which it would be!), then I think they should *both* be in the spec, and the spec should say they're equivalent. Then if we find they're not equivalent, we clearly have a bug in the spec which must be fixed --- not carte blanche to proceed in an undesirable direction. It would be a sort of spec-level assertion.<br>
</div></div></blockquote><div><br></div><div>I think the spec currently calls attention to only some situations that could lead to nesting of implicitly acquired storage locks.</div><div><br></div><div>I previously described some other situations, which you and others indicated should be treated as WebKit and IE bugs. I didn't look very far to dig those up. After some more thought, I came up with these additional cases that the spec doesn't cover:</div>
<div><br></div><div>1a) Given a page (domain A) containing an iframe (domain B), have the outer page navigate the inner frame to "about:blank". This navigation completes synchronously, and the unload handler for the iframe runs before the navigation request completes. This is true of all browsers.</div>
<div><br></div><div>1b) Suppose the inner page has a pending XMLHttpRequest when the outer frame navigates the inner frame. The XHR's onabort handler would run before the navigation to "about:blank" completes.</div>
<div><br></div><div>2) Set a break point in the Mozilla JS debugger. This runs a nested event loop each time you single step so that it can drive the rest of the browser UI.</div><div><br></div><div>3) Install a Firefox extension that runs a nested event loop in response to an event generated by content. I debugged many Firefox crashes resulting from extensions that do this kind of thing for various reasons.</div>
<div><br></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></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"><div>
<div> </div><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>
<br></div><div><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.<br>
</div></div></blockquote><div><br></div></div><div>Why is it contrived?</div></div></blockquote></div><div><br>Because libraries tend to initially use plugins and move towards using core browser functionality, not the other way around. But even if these library issues aren't contrived, I don't see how they justify making things a lot more unpredictable for everyone.<br>
</div></div></blockquote><div><br></div><div>I'm not convinced. Look at Google Maps and street view. Gmail uses more Flash now than it used to. Wave uses Gears for a variety of little things. There's a cool video gadget that swaps between HTML5 video or Flash depending on the browser and the target media.</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></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">What will you do for Gecko when it supports content processes?<br>
</div></blockquote></div></div><br clear="all">Implement the spec, I hope!</blockquote><div><br></div><div>It seems odd to me that this behavior was put into the spec without any implementation experience to guide it. The only multi-process implementations that I know of do not have a storage mutex.</div>
<div><br></div><div>-Darin</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><div class="h5"><br>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>
</div></div></blockquote></div><br>