[whatwg] Application defined "locks"

Jeremy Orlow jorlow at chromium.org
Wed Sep 9 21:44:44 PDT 2009

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

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

I'd count plugins as "trouble APIs".  :-)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090910/27e1b4a5/attachment-0002.htm>

More information about the whatwg mailing list