[whatwg] localStorage feedback

[Darin Fisher]

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>