[whatwg] Application defined "locks"

[Darin Fisher]

rt oOn Thu, Sep 10, 2009 at 6:35 PM, James Robinson <jamesr at google.com>wrote:

>
>
> On Thu, Sep 10, 2009 at 6:11 PM, Jeremy Orlow <jorlow at chromium.org> wrote:
>
>> On Fri, Sep 11, 2009 at 9:28 AM, Darin Fisher <darin at chromium.org> wrote:
>>
>>> On Thu, Sep 10, 2009 at 4:59 PM, Robert O'Callahan <robert at ocallahan.org
>>> > wrote:
>>>
>>>> On Fri, Sep 11, 2009 at 9:52 AM, Darin Fisher <darin at chromium.org>wrote:
>>>>
>>>>> 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.
>>>>>
>>>>
>>>> One use case is selecting a master instance of an app. I haven't really
>>>> been following the "global script" thread, but doesn't that address this use
>>>> case in a more direct way?
>>>>
>>>
>>> No it doesn't.  The global script would only be reachable by related
>>> browsing contexts (similar to how window.open w/ a name works).  In a
>>> multi-process browser, you don't want to _require_ script bindings to span
>>> processes.
>>>
>>> That's why I mentioned shared workers.  Because they are isolated and
>>> communication is via string passing, it is possible for processes in
>>> unrelated browsing contexts to communicate with the same shared workers.
>>>
>>>
>>>
>>>>
>>>> What other use-cases for long-lived locks are there?
>>>>
>>>>
>>> This is a good question.  Most of the use cases I can imagine boil down
>>> to a master/slave division of labor.
>>>
>>> For example, if I write an app that does some batch asynchronous
>>> processing (many setTimeout calls worth), then I can imagine setting a flag
>>> across the entire job, so that other instances of my app know not to start
>>> another such overlapping job until I'm finished.  In this example, I'm
>>> supposing that storage is modified at each step such that guaranteeing
>>> storage consistency within the scope of script evaluation is not enough.
>>>
>>
>> What if instead of adding locking, we added a master election mechanism?
>>  I haven't thought it out super well, but it could be something like this:
>>  You'd call some function like |window.electMaster(name,
>> newMasterCallback, messageHandler)|.  The name would allow multiple groups
>> of master/slaves to exist.  The newMasterCallback would be called any time
>> that the master changes.  It would be passed a message port if we're a slave
>> or null if we're the master.  messageHandler would be called for any
>> messages.  When we're the master, it'll be passed a message port of the
>> slave so that responses can be sent if desired.
>>
>> In the gmail example: when all the windows start up, they call
>> window.electMaster.  If they're given a message port, then they'll send all
>> messages to that master.  The master would handle the request and possibly
>> send a response.  If a window is closed, then the UA will pick one of the
>> slaves to become the master.  The master would handle all the state and the
>> slaves would be lighter weight.
>>
>> --------------
>>
>> There are a couple open questions for something like this.  First of all,
>> we might want to let windows provide a hint that they'd be a bad master.
>>  For example, if they expected to be closed fairly soon.  (In the gmail
>> example, a compose mail window.)
>>
>> We might also want to consider allowing windows to opt out of masterhood
>> with something like |window.yieldMasterhood()|.  This would allow people to
>> build locks upon this interface which could be good and bad.
>>
>> Next, we could consider adding a mechanism for the master to pickle up
>> some amount of state and pass it on to another master.  For example, maybe
>> the |window.yieldMasterhood()| function could take a single "state" param
>> that would be passed into the master via the newMasterCallback function.
>>
>> Lastly and most importantly, we need to decide if we think shared workers
>> are the way all of this should be done.  If so, it seems like none of this
>> complexity is necessary.  That said, until shared workers are first class
>> citizens in terms of what APIs they can access (cookies, LocalStorage, etc),
>> I don't think shared workers are practical for many developers and use
>> cases.
>>
>
> What about eliminating shared memory (only one context would be allowed
> access to cookies, localStorage, etc)?  It seems to be working out fine for
> DOM access and is much, much easier to reason about.
>
> - James
>
>

It is a good idea.  If we were to start fresh, it'd probably be the ideal
answer.  We could say that each SharedWorker gets its own slice of
persistent storage independent from the rest.  But this ship has sailed for
cookies at least, and database and localstorage are already shipping in UAs.

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