[whatwg] Application defined "locks"

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

As proposed, its not really a locking mechanism in that nothing ever blocks.
A 'flag' gets acquired by at most one context in an origin at any given time
is all. Apps can make what they will out of that.


>
> 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");
>

Sure, a mutex, that can be useful too. I think you can compose a 'mutex' out
of the 'flag'... so in my book... the long lived 'flag' is more valuable
feature.

acquireFlag("mutexName", function() { do critical section stuff;
releaseFlag("mutexName");  } );

Now, somebody will say "but what if the programmer neglects to release the
flag in the event of an exceptional return".  And i would say... they wrote
a bug and should fix it if they wanted mutex semantics..



>
> 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?  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.
>
> - James
>
>
>> -Darin
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090910/dda971b3/attachment.htm>

Received on Thursday, 10 September 2009 15:10:38 UTC