- From: Darin Fisher <darin@chromium.org>
- Date: Thu, 10 Sep 2009 17:28:35 -0700
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.htm>
Received on Thursday, 10 September 2009 17:28:35 UTC