[whatwg] Application defined "locks"

In general this seems like a pretty interesting idea.  It definitely would
be nice to completely abstract away all concepts of concurrency from web
developers, but some of our solutions thus far (message passing, async
interfaces, etc) have not been terribly appreciated by developers either.
 The GlobalScript proposal is a good example: to us, shared workers were an
adequate solution, but in practice the lack of shared state is very
difficult for some developers to work around.  Possibly even more difficult
than dealing with some levels of concurrency.

I think it'd be interesting to introduce this as an experimental API and see
what web developers do with it.


As for the idea of a sync API:  What if some library/framework and the
embedding page use these flags/locks?  I know you can't actually deadlock
with this API, but I worry some developers will just do
|while(!acquireLock("flag")) {}| which could lead to deadlocks.  Only
allowing an async API would fix this, but developers have typically not
liked async APIs.

Here's another idea that I think is actually kind of cool:  What if we kept
track of locking precedence (i.e. the graph of which locks have been taken
while other locks were held) and threw an exception if any lock was ever
taken in a way that violated the graph.  In other words, we wouldn't make
the developer tell us the locking precedence, and we wouldn't wait until you
hit an actual deadlock.  Instead we would look for the first call site that
_could_ have deadlocked.  A long time ago, I was working on a project that
had some deadlock problems.  We implemented exactly this and it worked
pretty well.


On Thu, Sep 10, 2009 at 9:22 AM, Olli Pettay <Olli.Pettay at helsinki.fi>wrote:

> 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.
>

This seems like a good idea.

As you said on IRC, perhaps there should be a way to acquire
> many flags at once and then call the callback.
>

I like this idea as well.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090910/c1d83b51/attachment-0001.htm>

Received on Wednesday, 9 September 2009 18:33:44 UTC