[whatwg] Application defined "locks"

If this feature existed, we likely would have used it for offline Gmail to
coordinate which instance of the app (page with gmail in it) should be
responsible for sync'ing the local database with the mail service. In the
absence of a feature like this, instead we used the local database itself to
register which page was the 'syncagent'. This involved periodically updating
the db by the syncagent, and periodic polling by the would be syncagents
waiting to possibly take over. Much ugliness.
var isSyncAgent = false;
window.acquireFlag("syncAgency", function() { isSyncAgent = true; });

Much nicer.


On Wed, Sep 9, 2009 at 7:02 PM, Maciej Stachowiak <mjs at apple.com> wrote:

>
> On Sep 9, 2009, at 6:33 PM, Jeremy Orlow wrote:
>
> 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.
>
>
> I think it's predictable that it will be used in badly wrong ways without
> implementing it. Explicit application-managed locking is a massive failure
> as a mechanism for managing concurrency.
>
> 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.
>
>
> If we want to go async, then I'd rather have an asynchronous way to acquire
> an *actual* lock on the resource (as with the LocalStorage async transaction
> proposal), than an async advisory locking model. Having both asynchronicity
> *and* advisory locks seems like the worst of both worlds.
>
> On the other hand, if we offer only the equivalent of tryLock() and not a
> blocking lock(), it's almost certain Web apps will build spin locks in the
> way you describe, leading to wasteful CPU usage, bad performance, and the
> possibility of deadlocks.
>
>
>
> 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.
>
>
> This seems like a very challenging programming model for little gain. If
> the locks are purely advisory, they do not prevent race conditions, but a
> discipline to prevent deadlocks will still make them very hard to use. Note
> also that the possibility of synchronous cross-site code execution would
> require a lock precedence graph to be cross-site to really prevent
> deadlocks, but it would be impossible for a Web application to guarantee
> anything about lock order with respect to Web apps in different origins. The
> other possibility is to drop all locks in the case of synchronous
> cross-origin code execution, but then these advisory locks would not even be
> useful for preventing race conditions.
>
> Locking is broken - just don't do it.
>
> Regards,
> Maciej
>
>
>
>
> 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/20090909/d6bf7b2b/attachment-0001.htm>

Received on Wednesday, 9 September 2009 19:38:03 UTC