[whatwg] Application defined "locks"

Robert O'Callahan robert at ocallahan.org
Wed Sep 9 16:24:31 PDT 2009

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

Giving Web authors the crappy race-prone and deadlock-prone locking
programming model scares *me*. 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.
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?

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. Now,
if we find that authors are needing to build explicit locks using
localStorage, we should figure out their use-cases and see what a better
solution for those use-cases might be, instead of giving them a more
convenient way to endanger themselves.

"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090910/1d1600d7/attachment-0002.htm>

More information about the whatwg mailing list