<div class="gmail_quote">On Thu, Sep 10, 2009 at 2:38 PM, James Robinson <span dir="ltr"><<a href="mailto:jamesr@google.com">jamesr@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br><br><div class="gmail_quote"><div><div></div><div class="h5">On Thu, Sep 10, 2009 at 1:55 PM, Darin Fisher <span dir="ltr"><<a href="mailto:darin@chromium.org" target="_blank">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><div></div><div><div class="gmail_quote">On Thu, Sep 10, 2009 at 1:08 PM, Oliver Hunt <span dir="ltr"><<a href="mailto:oliver@apple.com" target="_blank">oliver@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word"><br><div><div><div></div><div><div>On Sep 10, 2009, at 12:55 PM, Darin Fisher wrote:</div><br><blockquote type="cite"><div class="gmail_quote">On Thu, Sep 10, 2009 at 12:32 PM, Maciej Stachowiak <span dir="ltr"><<a href="mailto:mjs@apple.com" target="_blank">mjs@apple.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word"><div><br><div><div>On Sep 10, 2009, at 11:22 AM, Michael Nordman wrote:</div><br><blockquote type="cite"><br><br><div class="gmail_quote">On Wed, Sep 9, 2009 at 7:55 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 Thu, Sep 10, 2009 at 2:38 PM, Michael Nordman <span dir="ltr"><<a href="mailto:michaeln@google.com" target="_blank">michaeln@google.com</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"> If this feature existed, we likely would have used it for offline Gmail to coordinate which instance of the app (page with gmail in it) should be responsible for sync'ing the local database with the mail service. In the absence of a feature like this, instead we used the local database itself to register which page was the 'syncagent'. This involved periodically updating the db by the syncagent, and periodic polling by the would be syncagents waiting to possibly take over. Much ugliness.<div>
<br></div><div>var isSyncAgent = false;</div><div><span style="font-family:arial,sans-serif;font-size:13px;border-collapse:collapse">window.acquireFlag("syncAgency", function() { isSyncAgent = true; });</span><br>
<div><br></div><div>Much nicer.</div></div></blockquote><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex"><div><div><div></div></div></div></blockquote>
</div><div><br>How do you deal with the user closing the syncagent while other app instances remain open?<br></div></div></blockquote><div><br></div><div>In our db polling world... that was why the syncagent periodically updated the db... to say "still alive"... on close it would say "i'm gone" and on ugly exit, the others would notice the lack of "still alives" and fight about who was it next. A silly bunch of complexity for something so simple.</div>
<div><br></div><div>In the acquireFlag world... wouldn't the page going away simply relinquish the flag?</div></div></blockquote></div><br></div><div>How would the pages that failed to acquire it before know that they should try to acquire it again? Presumably they would still have to poll (assuming the "tryLock" model).</div>
<div><br></div><div>Regards,</div><div>Maciej</div><font color="#888888"><div><br></div></font></div></blockquote></div><br><div><br></div><div>In my proposed interace, you can wait asynchronously for the lock. Just call acquireLock with a second parameter, a closure that runs once you get the lock.</div>
</blockquote><div><br></div></div></div><div>What if you don't want to wait asynchronously? My reading of this is that you need two copies of the code, one that works synchronously, but you still need to keep the asynchronous model to deal with an inability to synchronously acquire the lock. What am I missing?</div>
<br></div></div></blockquote></div><br><div><br></div></div></div><div>Sounds like a problem that can be solved with a function.</div><div><br></div><div>The reason for the trylock support is to allow a programmer to easily do nothing if they can't acquire the lock. If you want to wait if you can't acquire the lock, then using the second form of acquireLock, which takes a function, is a good solution.</div>
</blockquote><div><br></div></div></div><div>I don't think there is much value in the first form of acquireLock() - only the second form really makes sense. I also strongly feel that giving web developers access to locking mechanisms is a bad idea - it hasn't been a spectacular success in any other language.</div>
<div><br></div><div>I think the useful semantics are equivalent to the following (being careful to avoid mentioning 'locks' or 'mutexes' explicit): A script passes in a callback and a token. The UA invokes the callback at some point in the future and provides the guarantee that no other callback with that token will be invoked in any context within the origin until the invoked callback returns. Here's what I mean with an intentionally horrible name:</div>
<div><br></div><div>window.runMeExclusively(callback, "arbitrary string token");</div></div></blockquote><div><br></div><div>This looks just like the acquireScopedLock method I proposed.</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></div><div>An application developer could then put all of their logic that touches a particular shared resource behind a token. It's also deadlock free so long as each callback terminates.</div>
<div><br></div><div>Would this be sufficient?</div></div></blockquote><div><br></div><div>This is sufficient for providing fine-grain locking for access to shared resources. It does not help you build long-lived locks, such as the one offline gmail constructs from using the database API and timers (see the post from michaeln).</div>
<div><br></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><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> If so it is almost possible to implement it correctly in a JavaScript library using a shared worker per origin and postMessage, except that it is not currently possible to detect when a context goes away.</div>
<div><br></div></div></blockquote><div><br></div><div>Right. Maybe the answer is to add support to shared workers so that you can know when an end point disappears. Then, it would be fairly trivial to implement a lock master from a shared worker that could either manage short or long lived locks. The synchronous "trylock" API would not be possible, but that's fine. I only included that in my proposal for convenience.</div>
<div><br></div><div>-Darin</div></div>