<br><br><div class="gmail_quote">On Thu, Sep 10, 2009 at 5:28 PM, Darin Fisher <span dir="ltr"><<a href="mailto:darin@chromium.org">darin@chromium.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="gmail_quote"><div class="im">On Thu, Sep 10, 2009 at 4:59 PM, Robert O'Callahan <span dir="ltr"><<a href="mailto:robert@ocallahan.org" target="_blank">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>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>
<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><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 class="im">
<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><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><font color="#888888"><div>-Darin</div></font></div></blockquote><div><br></div><div><br></div><div>Also, the other motivating factor for me is access to LocalStorage from workers.  (I know it has been removed from the spec, but that is unfortunate, no?)  </div>
<div><br></div><div>By definition, workers are designed to be long lived, possibly doing long stretches of computation, and being able to intermix reads and writes to storage during that stretch of computation would be nice.</div>
<div><br></div><div>Moreover, it would be nice if a worker in domain A could effectively "lock" part of the storage so that the portion of the app running on the main thread could continue accessing the other parts of storage associated with domain A.  The implicit storage mutex doesn't support this use case very well.  You end up having to call the getStorageUpdates function periodically (releasing the lock in the middle of computation!!).  That kind of thing is really scary and hard to get right.  I cringe whenever I see someone unlocking, calling out to foreign code, and then re-acquiring the lock.  Why?  because it means that existing variables, stack based or otherwise, that were previously consistent may have become inconsistent with global data in storage due to having released the lock.  getStorageUpdates is dangerous.  it is a big hammer that doesn't really fit the bill.</div>
<div><br></div><div>The alternative to getStorageUpdates in this case is to create another domain on which to run the background worker just so that you can have an independent slice of storage.  That seems really lame to me.  Why should domain A have to jump through such hoops?</div>
<div><br></div><div>-Darin</div></div>