On Wed, Aug 26, 2009 at 12:51 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;">
On Sun, Aug 23, 2009 at 11:33 PM, Robert O'Callahan <span dir="ltr"><<a href="mailto:robert@ocallahan.org" target="_blank">robert@ocallahan.org</a>></span> wrote:<br><div class="gmail_quote"><div class="im"><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 class="im"><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></blockquote><div><br></div><div>I don'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><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 class="im"><div>Defining "no-one else" may be difficult. I haven'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'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'm not sure what you'd do if you discovered an undesired lock-drop, though. If you can't write something sensible instead of "abort, or something", it's not worth doing.<br>
</div></div></div></blockquote><div><br></div><div class="im"><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>Such a boolean could be useful, but I disagree with the assertion that the implementation is significantly more difficult. I'm pretty sure both would be trivial in Chromium, for example.</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"><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'm struggling to find a good use case for this.</span></div>
</div></div></blockquote><div><br></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're going to do something halfway magical, we should make it possible for developers to know it happened, right??</div>
<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 class="im"><div><span class="Apple-style-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 "other threads." 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>So the use case I've had in my mind that maybe isn'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 "processing" or anything between calls.</div><div><br></div><div>If the act of calling getStorageUpdates gives the lock to everyone who's waiting for it before letting the caller get it again, then I guess I can buy this argument. I still think yieldStorageMutex (or just about anything for that matter) would be a much better name, but given that no one's agreeing with me (on this list, anyhow) I'm just going to drop it.</div>
</div>