[whatwg] Application defined "locks"

[Darin Fisher]

On Wed, Sep 9, 2009 at 9:27 PM, Jeremy Orlow <jorlow at chromium.org> wrote:

> 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.
>


It may not be so easy to disallow showModalDialog.  Imagine if you script a
plugin inside the transaction, and before returning, the plugin scripts
another window, where it calls showModalDialog.  There could have been a
process hop there.

-Darin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090909/dba2a8ad/attachment-0002.htm>