On 9/10/09 2:24 AM, Robert O'Callahan wrote:
On Thu, Sep 10, 2009 at 6:37 AM, Darin Fisher <[email protected]
<mailto:[email protected]>> 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
