[whatwg] Application defined "locks"

Darin Fisher darin at chromium.org
Wed Sep 9 21:37:40 PDT 2009

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.

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

More information about the whatwg mailing list