<br><br><div class="gmail_quote">On Wed, Aug 26, 2009 at 1:27 AM, Jeremy Orlow <span dir="ltr">&lt;<a href="mailto:jorlow@chromium.org">jorlow@chromium.org</a>&gt;</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, Aug 26, 2009 at 12:51 AM, Darin Fisher <span dir="ltr">&lt;<a href="mailto:darin@chromium.org" target="_blank">darin@chromium.org</a>&gt;</span> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">

On Sun, Aug 23, 2009 at 11:33 PM, Robert O&#39;Callahan <span dir="ltr">&lt;<a href="mailto:robert@ocallahan.org" target="_blank">robert@ocallahan.org</a>&gt;</span> wrote:<br></div><div class="im"><div class="gmail_quote">
<div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<div>That behaviour sounds worse than what Firefox currently does, where an alert disables input to all tabs in the window (which is already pretty bad), because it willl make applications in visually unrelated tabs and windows hang.</div>


</blockquote><div><br></div></div><div><div><span style="font-family:arial, sans-serif;font-size:13px;border-collapse:collapse">You can have script connections that span multiple tabs in multiple windows, so in order to preserve the run-to-completion semantics of JavaScript, it is important that window.{alert,confirm,prompt,showModalDialog} be modal across all windows in the browser.  This is why those APIs suck rocks, and we should never create APIs like them again.</span></div>


</div></div></div></blockquote><div><br></div><div>I don&#39;t understand your point here.  Are you saying that the current firefox behavior is not correct, that releasing the storage lock on these events is not correct, or something else?</div>
</div></blockquote><div><br></div><div>I meant that the current Firefox behavior is technically incorrect.  No one likes app modal dialogs, but how else can you guarantee run-to-completion semantics? How else do you prevent other scripts from modifying your state while you are stuck calling into window.alert().</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 class="im">

<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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><div>Defining &quot;no-one else&quot; may be difficult. I haven&#39;t thought this through, to be honest, but I think you could update the counter every time the storage mutex is released and the shared state was modified since the storage mutex was acquired. Reading the counter would acquire the storage mutex. You&#39;d basically write<br>




<br>var counter = window.storageMutexGenerationCounter;<br>... do lots of stuff ...<br>if (window.storageMutexGenerationCounter != counter) {<br>  // abort, or refresh local state, or something<br>}<br><br>I&#39;m not sure what you&#39;d do if you discovered an undesired lock-drop, though. If you can&#39;t write something sensible instead of &quot;abort, or something&quot;, it&#39;s not worth doing.<br>



</div></div></div></blockquote><div><br></div><div><span style="font-family:arial, sans-serif;font-size:13px;border-collapse:collapse"><div>Implementation-wise, the easiest thing to support is a boolean that becomes true when the lock is release and false when the lock is acquired.  Trying to update a counter based on modifications to the local storage backend which may be happening on another thread seems like more effort than it is worth.</div>


</span></div></div></blockquote><div><br></div></div><div>Such a boolean could be useful, but I disagree with the assertion that the implementation is significantly more difficult.  I&#39;m pretty sure both would be trivial in Chromium, for example.</div>
</div></blockquote><div><br></div><div>incrementing a counter on each modification to the database would involve some broadcasting of notifications to each renderer, or we&#39;d need to store the counter in shared memory.  either seems unfortunate given the debugging use case.</div>
<div><br></div><div>if we only record the fact that getStorageUpdates (or equivalent) was called, then it is just a local boolean in the renderer process.  that seems substantially simpler to implement without performance penalty.</div>
<div><br></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 class="im">

<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><span style="font-family:arial, sans-serif;font-size:13px;border-collapse:collapse"><div>


</div>
<div>But, what would you call this boolean?  storageMayHaveBeenUpdated? :-P</div><div><br></div></span><div><span style="font-family:arial, sans-serif;font-size:13px;border-collapse:collapse">I&#39;m struggling to find a good use case for this.</span></div>


</div></div></blockquote><div><br></div></div><div>None of the ones I already listed seemed interesting?  If nothing else, I would think debugability would be a key one.  If we&#39;re going to do something halfway magical, we should make it possible for developers to know it happened, right??</div>
<div class="im">

<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><div><div><span style="font-family:arial, sans-serif;font-size:13px;border-collapse:collapse">The getStorageUpdates name seems pretty decent to me when considering it from the perspective of the caller.  The caller is saying that they are OK with being able to see changes made to the localStorage by &quot;other threads.&quot;  This cleverly avoids the need to talk about locks, which seems like a good thing.  It is okay for there to be no updates to storage.</span></div>


</div></div></blockquote><div><br></div></div><div>So the use case I&#39;ve had in my mind that maybe isn&#39;t clear is this:</div><div><br></div><div>localStorage.getItem/setItem</div><div>navigator.getStorageUpdates()</div>

<div>
localStorage.getItem/setItem</div><div><br></div><div>In other words, no &quot;processing&quot; or anything between calls.</div><div><br></div><div>If the act of calling getStorageUpdates gives the lock to everyone who&#39;s waiting for it before letting the caller get it again, then I guess I can buy this argument.  </div>
</div></blockquote><div><br></div><div>right, this ^^^ is what i meant.</div><div><br></div><div>-darin</div></div>