[whatwg] Application defined "locks"

[Darin Fisher]

On Thu, Sep 10, 2009 at 2:38 PM, James Robinson <jamesr at google.com> wrote:

>
>
> On Thu, Sep 10, 2009 at 1:55 PM, Darin Fisher <darin at chromium.org> wrote:
>
>> On Thu, Sep 10, 2009 at 1:08 PM, Oliver Hunt <oliver at apple.com> wrote:
>>
>>>
>>> On Sep 10, 2009, at 12:55 PM, Darin Fisher wrote:
>>>
>>> On Thu, Sep 10, 2009 at 12:32 PM, Maciej Stachowiak <mjs at apple.com>wrote:
>>>
>>>>
>>>> On Sep 10, 2009, at 11:22 AM, Michael Nordman wrote:
>>>>
>>>>
>>>>
>>>> On Wed, Sep 9, 2009 at 7:55 PM, Robert O'Callahan <robert at ocallahan.org
>>>> > wrote:
>>>>
>>>>> On Thu, Sep 10, 2009 at 2:38 PM, Michael Nordman <michaeln at google.com>wrote:
>>>>>
>>>>>> 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.
>>>>>>
>>>>>
>>>>> How do you deal with the user closing the syncagent while other app
>>>>> instances remain open?
>>>>>
>>>>
>>>> In our db polling world... that was why the syncagent periodically
>>>> updated the db... to say "still alive"... on close it would say "i'm gone"
>>>> and on ugly exit, the others would notice the lack of "still alives" and
>>>> fight about who was it next. A silly bunch of complexity for something so
>>>> simple.
>>>>
>>>> In the acquireFlag world... wouldn't the page going away simply
>>>> relinquish the flag?
>>>>
>>>>
>>>> How would the pages that failed to acquire it before know that they
>>>> should try to acquire it again? Presumably they would still have to poll
>>>> (assuming the "tryLock" model).
>>>>
>>>> Regards,
>>>> Maciej
>>>>
>>>>
>>>
>>> In my proposed interace, you can wait asynchronously for the lock.  Just
>>> call acquireLock with a second parameter, a closure that runs once you get
>>> the lock.
>>>
>>>
>>> What if you don't want to wait asynchronously?  My reading of this is
>>> that you need two copies of the code, one that works synchronously, but you
>>> still need to keep the asynchronous model to deal with an inability to
>>> synchronously acquire the lock.  What am I missing?
>>>
>>>
>>
>> Sounds like a problem that can be solved with a function.
>>
>> The reason for the trylock support is to allow a programmer to easily do
>> nothing if they can't acquire the lock.  If you want to wait if you can't
>> acquire the lock, then using the second form of acquireLock, which takes a
>> function, is a good solution.
>>
>
> I don't think there is much value in the first form of acquireLock() - only
> the second form really makes sense.  I also strongly feel that giving web
> developers access to locking mechanisms is a bad idea - it hasn't been a
> spectacular success in any other language.
>
> I think the useful semantics are equivalent to the following (being careful
> to avoid mentioning 'locks' or 'mutexes' explicit):  A script passes in a
> callback and a token.  The UA invokes the callback at some point in the
> future and provides the guarantee that no other callback with that token
> will be invoked in any context within the origin until the invoked callback
> returns.  Here's what I mean with an intentionally horrible name:
>
> window.runMeExclusively(callback, "arbitrary string token");
>

This looks just like the acquireScopedLock method I proposed.



>
> An application developer could then put all of their logic that touches a
> particular shared resource behind a token.  It's also deadlock free so long
> as each callback terminates.
>
> Would this be sufficient?
>

This is sufficient for providing fine-grain locking for access to shared
resources.  It does not help you build long-lived locks, such as the one
offline gmail constructs from using the database API and timers (see the
post from michaeln).

I think there are good applications for setting a long-lived lock.  We can
try to make it hard for people to create those locks, but then the end
result will be suboptimal.  They'll still find a way to build them.



>  If so it is almost possible to implement it correctly in a JavaScript
> library using a shared worker per origin and postMessage, except that it is
> not currently possible to detect when a context goes away.
>
>
Right.  Maybe the answer is to add support to shared workers so that you can
know when an end point disappears.  Then, it would be fairly trivial to
implement a lock master from a shared worker that could either manage short
or long lived locks.  The synchronous "trylock" API would not be possible,
but that's fine.  I only included that in my proposal for convenience.

-Darin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090910/54550134/attachment-0002.htm>