<div class="gmail_quote">On Wed, Sep 9, 2009 at 11:08 AM, Aaron Boodman <span dir="ltr"><<a href="mailto:aa@google.com">aa@google.com</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 Wed, Sep 9, 2009 at 10:55 AM, Darin Fisher<<a href="mailto:darin@chromium.org">darin@chromium.org</a>> wrote:<br>
</div><div class="im">> I imagine a simple lock API:<br>
> window.acquireLock("name")<br>
> window.releaseLock("name")<br>
<br>
</div>I do not think it is a good idea to allow long-lived (past a stack<br>
frame) locks on the types of things we've been discussing (local<br>
storage, databases, etc).<br>
<div class="im"><br>
> This API seems like it could be used to allow LocalStorage to be usable from<br>
> workers.  Also, as we start developing other means of local storage (File<br>
> APIs), it seems like having to again invent a reasonable implicit locking<br>
> system will be a pain.  Perhaps it would just be better to develop something<br>
> explicit that application developers can use independent of the local<br>
> storage mechanism :-)<br>
<br>
</div>There would presumably have to be a separate name value for each API,<br>
though, right? So we're talking about the difference between:<br>
<br>
window.acquireLock("localStorage", function() {<br>
...<br>
});<br>
<br>
and:<br>
<br>
window.acquireLocalStorage(function() {<br>
...<br>
});<br>
<br>
It doesn't seem like much of a win for reusability IMO.<br></blockquote><div><br></div><div>I wanted to leave it up to the app developer to choose the name so that they could define how the lock is interpreted.</div>
<div><br></div><div>For example, they might want to partition the keyspace for local storage and have separate locks for separate keys.  Or, they might want to have a single lock that is inclusive of several storage mechanisms: LocalStorage and FileAPI.</div>
<div><br></div><div>Besides, once we have an explicit locking API, why not just be generic and give it a name divorced from LocalStorage or any kind of storage features for that matter?  Locking can be useful to other applications that do not even use local storage...</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="im"><br>
> It may be the case that we want to only provide acquireScopedLock (or<br>
> something like it) to enforce fine grained locking, but I think that would<br>
> only force people to implement long-lived locks by setting a field in<br>
> LocalStorage.<br>
<br>
</div>Do you have an example of a place where we want to allow long-lived locks?<br><font class="Apple-style-span" color="#888888"><br></font></blockquote><div><br></div><div> </div><div>It is important to think of these differently from normal mutexes that you might program with in C++.  Maybe I should have used the term "flag" instead of "lock" ;-)</div>
<div><br></div><div>You might use a long lived lock to indicate that you are the instance responsible for X.  I can imagine applications where there could be a master / slave relationships between the instances.  One instance is the master and the rest are the slaves.</div>
<div><br></div><div>If we only had fine grained locking, then we are saying that we want simulaneous instances of the same web app to be able to stop on each others data in LocalStorage.  Instead, a web app developer might want to disable LocalStorage features in all but the first instance of their web app.  The problem is that your state is held not just in LocalStorage but also in JS variables, the DOM, and perhaps in session state held by the server.  It is easy for LocalStorage to get corrupted even with proper fine-grained locking.  You still need a way to have a big "flag" that says... hey, i'm the one messing with LocalStorage.  A good example is the browser's profile directory.  Chrome and Firefox both only allow one instance of the app per profile.  A long-lived lock is held to support such behavior.</div>
<div><br></div><div>I suspect there is some overlap with my proposal and shared workers.  Perhaps what I am trying to accomplish here could even be implemented on top of shared workers, although using shared workers to achieve mutual exclusion locks seems rather heavyweight.</div>
<div><br></div><div>-Darin</div></div>