- From: Robert O'Callahan <robert@ocallahan.org>
- Date: Mon, 2 Nov 2009 22:28:10 +1300
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. > >> >> 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. What will you do for Gecko when it supports content processes? > Implement the spec, I hope! 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/0e770a01/attachment-0001.htm>
Received on Monday, 2 November 2009 01:28:10 UTC