[whatwg] Application defined "locks"

[Jeremy Orlow]

On Thu, Sep 10, 2009 at 1:13 PM, Darin Fisher <darin at chromium.org> wrote:

> On Wed, Sep 9, 2009 at 6:46 PM, Aaron Boodman <aa at google.com> wrote:
>
>> On Wed, Sep 9, 2009 at 11:30 AM, Aaron Boodman<aa at google.com> wrote:
>> > I see.
>> >
>> > So you are suggesting the localStorage could have zero concurrency
>> > guarantees and it is simply up to the developer to arrange things
>> > themselves using this new primitive.
>> >
>> > That is an interesting idea. You're right that it overlaps with the
>> > ideas that inspired shared workers, and the global script proposal.
>>
>> Ok, after thinking about this for a day, I'm going to say I think this
>> is a very cool idea, and a worthwhile addition, but I don't think it
>> should substitute for having the local storage API work correctly by
>> default.
>>
>> The web platform is supposed to work for developers of all experience
>> levels. If we make local storage have no concurrency guarantees, it
>> will seem like it works in the overwhelming majority of cases. It will
>> work in all SELUAs, and it will only NOT work in MELUAs in cases that
>> are basically impossible to test, let alone see during development.
>>
>> We have tried hard with the design of the web platform to avoid these
>> sort of untestable non-deterministic scenarios, and I think it is to
>> the overall value of the platform to continue this.
>>
>> Therefore, my position continues to be that to access local storage,
>> there should be an API that asynchronously acquires exclusive access
>> to storage.
>>
>> - a
>>
>
>
> Yeah, if you had to call an API that asynchronously acquires exclusive
> access
> to storage, then I believe that would nicely address most of the issues.
>  It is the
> solution we have for database transactions.
>
> I say "most" because I'm not sure that it eliminates the need to drop the
> storage
> mutex in the showModalDialog case.
>
> If I call showModalDialog from within a database transaction, and then
> showModalDialog
> tries to create another database transaction, should I expect that the
> transaction
> can be started within the nested run loop of the modal dialog?  If not,
> then it may cause
> the app to get confused and never allow the dialog to be closed (e.g.,
> perhaps the close
> action is predicated on a database query.)
>
> Nested loops suck.  showModalDialog sucks :-)
>

We could just disallow showModalDialog and any other trouble APIs like that
during localStorage and database "transactions".  Doing so seems better than
silently dropping transactional semantics.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090910/4198b33f/attachment-0002.htm>