[whatwg] Application defined "locks"

[Darin Fisher]

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.

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