[whatwg] Application defined "locks"

[James Robinson]

On Thu, Sep 10, 2009 at 7:59 PM, Darin Fisher <darin at chromium.org> wrote:

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

document.cookies is problematic but considering the many other issues with
this API it's probably not going to be the end of the world to have it be a
touch pricklier.

and database and localstorage are already shipping in UAs.
>

Is it really too late for DB and localStorage?  I'm still trying to get used
to the standards process used here but I thought the idea with UAs
implementing draft specs is that the feedback from the experience can be
used to refine the spec - a few UAs have implemented synchronous access to a
single resource from multiple threads and it appears to be problematic.
 Wouldn't that mean it's a good time to revise the problematic parts?

- James


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