[whatwg] Application defined "locks"

[Robert O'Callahan]

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?

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.

Rob
-- 
"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
53:5-6]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090910/1d1600d7/attachment.htm>