<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>