- From: Olli Pettay <Olli.Pettay@helsinki.fi>
- Date: Thu, 10 Sep 2009 03:22:45 +0300
On 9/10/09 2:24 AM, Robert O'Callahan wrote:
> On Thu, Sep 10, 2009 at 6:37 AM, Darin Fisher <darin at chromium.org
> <mailto: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?
If you're concerned about that, make acquireLock to throw an exception.
Authors sure will notice that things aren't quite right, if the flag
isn't acquired.
And if the acquireLock("flag", callback) approach is used, it is
harder to make the mistake to not check whether the flag was really got.
As you said on IRC, perhaps there should be a way to acquire
many flags at once and then call the callback.
-Olli
Received on Wednesday, 9 September 2009 17:22:45 UTC