[whatwg] Application defined "locks"

[Jeremy Orlow]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090911/73ceae98/attachment-0002.htm>