- From: Darin Fisher <darin@chromium.org>
- Date: Sat, 31 Oct 2009 07:53:28 -0700
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). > > 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? Many developers use high level toolkits to get their work done (e.g., jquery, prototype, dojo, google maps api, etc.). People are often one step removed from working directly with the web platform APIs. They have no idea what all is going on under the covers of those libraries, and that's a fine thing. The idea of unlocking whenever there is nesting occurred to me when Jeremy and I were discussing how to implement unlocking for all of the cases enumerated in the spec. It equates to a good number of places in the code that are quite separated from one another. It seems very fragile to ensure that all of those cases continue to be hooked properly. I think it is very hard to test that we get it right now and in the future. But, if we step back, we realize that the implicit unlocking is all about dealing with nesting of locks. So, I think it is _way_ better to just unlock the existing lock if an attempt is made to acquire a nested lock. > > At this point, I'm not favoring implementing the storage mutex in Chrome. >> I >> don't think we will have it in our initial implementation of LocalStorage. >> I think >> web developers that care will have to find another way to manage locking, >> like >> using a Web Database transaction or coordinating with a Shared Worker. >> > > 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. > I have definitely considered it. I would of course prefer to drop LocalStorage and focus on something better. Chrome is unfortunately in a difficult spot given that everyone else has implemented LocalStorage (though not necessarily to spec). So, we are currently on track to support this feature without locking. In the future, we might add locking. I've also considered other solutions, like copy-on-write, which could obviously lead to data loss, but at least it would ensure stability/consistency within a scripts execution. I would like it if the spec were open to such implementations. What will you do for Gecko when it supports content processes? -Darin -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20091031/c2a641d9/attachment.htm>
Received on Saturday, 31 October 2009 07:53:28 UTC