[whatwg] Application defined "locks"

[Darin Fisher]

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 :-)

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