[whatwg] Application defined "locks"

[Darin Fisher]

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.

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