<meta charset="utf-8">On Tue, Aug 18, 2009 at 4:26 PM, 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-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">

<div>It&#39;s also worth noting that Chromium is probably going to need to drop the storage mutex for most if not all plugin related calls due to deadlock conditions. �If there were some place to mention this as a &quot;may&quot; type thing, it&#39;d be good, but I realize it&#39;s probably out of scope for HTML 5.</div>

</blockquote><div><br></div><div>Oops. �The spec already does specify this behavior: �<a href="http://dev.w3.org/html5/spec/Overview.html#storage-mutex">http://dev.w3.org/html5/spec/Overview.html#storage-mutex</a></div><div>

<br></div><br><div class="gmail_quote">On Sat, Aug 22, 2009 at 5:54 AM, Robert O&#39;Callahan <span dir="ltr">&lt;<a href="mailto:robert@ocallahan.org">robert@ocallahan.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 19, 2009 at 11:26 AM, Jeremy Orlow <span dir="ltr">&lt;<a href="mailto:jorlow@chromium.org" target="_blank">jorlow@chromium.org</a>&gt;</span> wrote:<br></div><div class="gmail_quote"><div class="im">

<blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">
First of all, I was wondering why all user prompts are specified as &quot;must release the storage mutex&quot; (<a href="http://dev.w3.org/html5/spec/Overview.html#user-prompts" target="_blank">http://dev.w3.org/html5/spec/Overview.html#user-prompts</a>). �Should this really say &quot;must&quot; instead of &quot;may&quot;? �IIRC (I couldn&#39;t find the original thread, unfortunately) this was added because of deadlock concerns. �It seems like there might be some UA implementation specific ways this could deadlock and there is the question of whether we&#39;d want an alert() while holding the lock to block other execution requiring the lock, but I don&#39;t see why the language should be &quot;must&quot;. �For Chromium, I don&#39;t think we&#39;ll need to release the lock for any of these, unless there&#39;s some deadlock�scenario�I&#39;m missing here.</blockquote>


</div><div><br>So if one page grabs the lock and then does an alert(), and another page in the same domain tries to get the lock, you&#39;re going to let the latter page hang until the user dismisses the alert in the first page?</div>

</div></blockquote><div><br></div><div>Yes. �And I agree this is sub-optimal, but shouldn&#39;t it be left up to the UAs what to do? �I feel like this is somewhat of an odd case to begin with since alerts lock up most (all?) browsers to a varying degrees even without using localStorage.</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"><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">

<div>Given that different UAs are probably going to have other�scenarios�where they have to drop the lock (some of them may even be purely implementational issues), should we add some way for us to notify scripts the lock was dropped? �A normal event isn&#39;t going to be of much use, since it&#39;ll fire after the scripts execution ends (so the lock would have been dropped by then anyway). �A boolean doesn&#39;t seem super useful, but it&#39;s better than nothing and could help debugging. �Maybe fire an exception? �Are there other options?</div>


</blockquote></div><div><br>A generation counter might be useful.</div></div></blockquote><div><br></div><div>Ooo, I like that idea. �When would the counter increment? �It&#39;d be nice if it didn&#39;t increment if the page did something synchronous but no one else took the lock in the mean time.</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"><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>Lastly, is navigator.getStorageUpdates() the right name for the function that drops the lock? �Why was it changed from navigator.releaseLock()? �I assume we&#39;re trying to avoid the word &quot;lock&quot;, but the reason why you&#39;d need to call a function to get updates is not clear without understanding the concept of a lock...so what&#39;s the point of making this so cryptic?</div>


</blockquote></div><div><br>Authors would be confused that there&#39;s no aquireLock() API.</div></div></blockquote><div><br></div><div>Good point.</div><div><br></div><div>But getStorageUpdates is still not the right name for it. �The only way that there&#39;d be any updates to get is if, when you call the function, someone else takes the lock and makes some updates. �Maybe it should be yieldStorage (or yieldStorageMutex)? �In other words, maybe the name should imply that you&#39;re allowing concurrent updates to happen?</div>

</div>