[whatwg] Application defined "locks"

[Darin Fisher]

On Wed, Sep 9, 2009 at 4:24 PM, Robert O'Callahan <robert at ocallahan.org>wrote:

> On Thu, Sep 10, 2009 at 6:37 AM, Darin Fisher <darin at chromium.org> wrote:
>
>> Yes, exactly. Sorry for not making this clear.  I believe implicit locking
>> for LocalStorage (and the implicit unlocking) is going to yield something
>> very confusing and hard to implement well.  The potential for dead locks
>> when you fail to implicitly unlock properly scares me
>>
>
> You mean when the browser implementation has a bug and fails to implicitly
> unlock?
>

What concerns me are the cases where synchronous events (e.g., resizing an
iframe) can cause script to execute in another domain.  As spec'd, there is
a potential dead lock with the storage mutex.  We must carefully unlock in
situations like this.  However, such unlocking will appear quite mysterious
to users, so much so that I question the value of the implicit storage
mutex.

That led me down this path of imagining a more explicit locking mechanism
that would give the app control over how local storage is protected.

I agree that explicit locking can be a big dangerous hammer, but that's why
I tried to soften it by removing blocking behavior.



>
> Giving Web authors the crappy race-prone and deadlock-prone locking
> programming model scares *me*.
>

Me too.  I don't believe that I'm proposing such an API.



> Yes, your acquireLock can't get you into a hard deadlock, strictly
> speaking, but you can still effectively deadlock your application by waiting
> for a lock to become available that never can.
>

Sure, but at least the thread of execution isn't blocked, and the user can
recover by closing the tab or what have you.  By the way, you can already
pretty much create my acquireLock / releaseLock API on top of SharedWorkers
today, but in a slightly crappier way.  Are SharedWorkers problematic
because of this?  I don't think so.



> Also, how many authors will forget to test the result of acquireLock
> (because they're used to other locking APIs that block) and find that things
> are OK in their testing?
>

Perhaps the API could be different.  Perhaps the name "lock" is part of the
problem.



>
> I think we should be willing to accept a very high implementation burden on
> browser vendors in exchange for minimizing the burden on Web authors.
>

Yes, I wholeheartedly agree.  Note: my concern is that there is no good
implementation for the storage mutex.  Implicitly dropping it at weird times
is not a good answer.

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