<div class="gmail_quote">On Thu, Sep 10, 2009 at 4:59 PM, Robert O'Callahan <span dir="ltr"><<a href="mailto:robert@ocallahan.org">robert@ocallahan.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Fri, Sep 11, 2009 at 9:52 AM, Darin Fisher <span dir="ltr"><<a href="mailto:darin@chromium.org" target="_blank">darin@chromium.org</a>></span> wrote:<br></div><div class="gmail_quote"><div class="im">
<blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">
<div class="gmail_quote"><div><div></div>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.</div>

</div></blockquote></div><div><br>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?<br>
</div></div></blockquote><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="gmail_quote"><div>
<br>What other use-cases for long-lived locks are there?<br></div><br></div></blockquote><div><br></div><div>This is a good question.  Most of the use cases I can imagine boil down to a master/slave division of labor.</div>
<div><br></div><div>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.</div>
<div><br></div><div>-Darin</div></div>