- From: Darin Fisher <darin@chromium.org>
- Date: Mon, 2 Nov 2009 09:36:39 -0800
On Mon, Nov 2, 2009 at 1:28 AM, Robert O'Callahan <robert at ocallahan.org>wrote: > On Sun, Nov 1, 2009 at 3:53 AM, Darin Fisher <darin at chromium.org> wrote: > >> On Fri, Oct 30, 2009 at 1:36 AM, Robert O'Callahan <robert at ocallahan.org>wrote: >> >>> On Fri, Oct 30, 2009 at 7:27 PM, Darin Fisher <darin at chromium.org>wrote: >>> >>>> You are right that the conditions are specific, but I don't know that >>>> that is the >>>> exhaustive list. Rather than defining unlock points, I would implement >>>> implicit >>>> unlocking by having any nested attempt to acquire a lock cause the >>>> existing lock >>>> to be dropped. Nesting can happen in the cases you mention, but >>>> depending on >>>> the UA, it may happen for other reasons too. >>>> >>> >>> What reasons? >>> >>> 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. >>> >> >> 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. >> >> Unlock if yieldForStorageUpdates is called. >> Unlock when returning from script execution. >> Unlock if another attempt to lock occurs (any form of nesting). >> >> In the third case, I'd probably log something to the JS console to alert >> developers. >> >> 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). >> > > 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. > > 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. > I think the spec currently calls attention to only some situations that could lead to nesting of implicitly acquired storage locks. 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: 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. 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. 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. 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. > > >> >>> >>> For example, a JS library might evolve to use flash for something small >>>> (like >>>> storage or sound) that it previously didn't use when I first developed >>>> my code. >>>> Voila, now my storage lock is released out from under me. >>>> >>> >>> 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. >>> >> >> Why is it contrived? >> > > 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. > 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. > > What will you do for Gecko when it supports content processes? >> > > Implement the spec, I hope! 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. -Darin > > Rob > -- > "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] > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20091102/8e8c35d0/attachment-0001.htm>
Received on Monday, 2 November 2009 09:36:39 UTC