On Fri, Oct 30, 2009 at 7:27 PM, Darin Fisher <da...@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. 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. 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. 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]
