- From: Jeremy Orlow <jorlow@chromium.org>
- Date: Fri, 30 Oct 2009 02:03:54 -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. > > 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. > I don't have a strong opinion either way on this one, but in general I'd say that making a race more subtle isn't usually much of a win.....especially when it comes to debugging it. > 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. > We'd love to, but it's difficult given that most of the other vendors have already implemented it. I also believe that Microsoft's browser exhibits the same races that Darin's talking about. So I'm not really sure how you could suggest that us not implementing it is better than implementing the status quo. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20091030/ca9dc813/attachment.htm>
Received on Friday, 30 October 2009 02:03:54 UTC