On Fri, Sep 11, 2009 at 9:28 AM, Darin Fisher <span dir="ltr"><<a href="mailto:darin@chromium.org">darin@chromium.org</a>></span> wrote:<br><div class="gmail_quote"><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></blockquote><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>--------------</div><div><br></div><div>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.)</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
</div>