<div class="gmail_quote">On Fri, Aug 28, 2009 at 4:05 AM, Kevin Benson <span dir="ltr"><<a href="mailto:kevin.m.benson@gmail.com">kevin.m.benson@gmail.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 Sun, Aug 23, 2009 at 1:22 AM, Jeremy Orlow<<a href="mailto:jorlow@chromium.org">jorlow@chromium.org</a>> wrote:<br>
> On Tue, Aug 18, 2009 at 4:26 PM, Jeremy Orlow <<a href="mailto:jorlow@chromium.org">jorlow@chromium.org</a>> wrote:<br>
>><br>
</div><div class="im">>>> Lastly, is navigator.getStorageUpdates() the right name for the function<br>
>>> that drops the lock? Why was it changed from navigator.releaseLock()? I<br>
>>> assume we're trying to avoid the word "lock", but the reason why you'd need<br>
>>> to call a function to get updates is not clear without understanding the<br>
>>> concept of a lock...so what's the point of making this so cryptic?<br>
>><br>
>> Authors would be confused that there's no aquireLock() API.<br>
><br>
> Good point.<br>
> But getStorageUpdates is still not the right name for it. The only way that<br>
> there'd be any updates to get is if, when you call the function, someone<br>
> else takes the lock and makes some updates. Maybe it should be yieldStorage<br>
> (or yieldStorageMutex)? In other words, maybe the name should imply that<br>
> you're allowing concurrent updates to happen?<br>
<br>
</div>How about:<br>
<br>
commitStorageUpdates<br>
<br>
... since a new transactor cannot write to storage until a commit<br>
point is reached by the current transactor finishing up and releasing<br>
the lock.</blockquote><div><br></div><div>Both commit and allow seem like good alternatives. I still like yieldStorageMutex, but I understand using the word Mutex might seem too scary. Now I'll just pray that Ian also finds one of these names to be better than getStorageUpdates. :-)</div>
<div><br></div><div><br></div><div>On Sun, Aug 23, 2009 at 11:33 PM, Robert O'Callahan <span dir="ltr"><<a href="mailto:robert@ocallahan.org">robert@ocallahan.org</a>></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 class="im">On Sat, Aug 22, 2009 at 10:22 PM, Jeremy Orlow <span dir="ltr"><<a href="mailto:jorlow@chromium.org" target="_blank">jorlow@chromium.org</a>></span> wrote:<br></div><div class="gmail_quote"><div class="im">
<blockquote class="gmail_quote" style="margin-top: 0pt; margin-right: 0pt; margin-bottom: 0pt; margin-left: 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex; ">
On Sat, Aug 22, 2009 at 5:54 AM, 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><blockquote class="gmail_quote" style="margin-top: 0pt; margin-right: 0pt; margin-bottom: 0pt; margin-left: 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex; ">
<div>On Wed, Aug 19, 2009 at 11:26 AM, Jeremy Orlow <span dir="ltr"><<a href="mailto:jorlow@chromium.org" target="_blank">jorlow@chromium.org</a>></span> wrote:<br></div><div class="gmail_quote"><div><blockquote class="gmail_quote" style="margin-top: 0pt; margin-right: 0pt; margin-bottom: 0pt; margin-left: 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex; ">
First of all, I was wondering why all user prompts are specified as "must release the storage mutex" (<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 "must" instead of "may"? IIRC (I couldn'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'd want an alert() while holding the lock to block other execution requiring the lock, but I don't see why the language should be "must". For Chromium, I don't think we'll need to release the lock for any of these, unless there's some deadlock scenario I'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'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><div>Yes. And I agree this is sub-optimal, but shouldn'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></blockquote></div><div><br>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>
</div></blockquote><div><br></div><div>Apparently (based on the reply from Jonas on the thread I split this into) it sounds like this behavior is actually a bug. Either way, it breaks run-to-completion and (as far as I can tell) goes against the spec (but I'm fuzzy on this part).</div>
<div><br></div><div>So I guess the question is why we should make a special case for LocalStorage regarding modal dialog boxes?</div><div><br></div><div><br></div><div>On Sat, Aug 22, 2009 at 10:22 PM, Jeremy Orlow <span dir="ltr"><<a href="mailto:jorlow@chromium.org">jorlow@chromium.org</a>></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; ">
On Tue, Aug 18, 2009 at 4:26 PM, Jeremy Orlow <span dir="ltr"><<a href="mailto:jorlow@chromium.org" target="_blank">jorlow@chromium.org</a>></span> wrote:<div class="im"><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'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 "may" type thing, it'd be good, but I realize it's probably out of scope for HTML 5.</div>
</blockquote><div><br></div></div><div>Oops. The spec already does specify this behavior: <a href="http://dev.w3.org/html5/spec/Overview.html#storage-mutex" target="_blank">http://dev.w3.org/html5/spec/Overview.html#storage-mutex</a></div>
</blockquote></div><div><br></div><div>One question about this, actually. I'm a bit troubled by the following language:</div><div><br></div><div>"<span class="Apple-style-span" style="font-family: sans-serif; font-size: medium; ">Whenever a <a href="http://dev.w3.org/html5/spec/Overview.html#concept-script" title="concept-script" style="color: rgb(0, 0, 204); background-image: initial; background-repeat: initial; background-attachment: initial; -webkit-background-clip: initial; -webkit-background-origin: initial; background-color: transparent; background-position: initial initial; ">script</a> calls into a <a href="http://dev.w3.org/html5/spec/Overview.html#plugin" style="color: rgb(0, 0, 204); background-image: initial; background-repeat: initial; background-attachment: initial; -webkit-background-clip: initial; -webkit-background-origin: initial; background-color: transparent; background-position: initial initial; ">plugin</a>, and whenever a <a href="http://dev.w3.org/html5/spec/Overview.html#plugin" style="color: rgb(0, 0, 204); background-image: initial; background-repeat: initial; background-attachment: initial; -webkit-background-clip: initial; -webkit-background-origin: initial; background-color: transparent; background-position: initial initial; ">plugin</a> calls into a <a href="http://dev.w3.org/html5/spec/Overview.html#concept-script" title="concept-script" style="color: rgb(0, 0, 204); background-image: initial; background-repeat: initial; background-attachment: initial; -webkit-background-clip: initial; -webkit-background-origin: initial; background-color: transparent; background-position: initial initial; ">script</a>, the user agent must release the <a href="http://dev.w3.org/html5/spec/Overview.html#storage-mutex" style="color: rgb(102, 0, 153); background-image: initial; background-repeat: initial; background-attachment: initial; -webkit-background-clip: initial; -webkit-background-origin: initial; background-color: transparent; background-position: initial initial; ">storage mutex</a>.<span class="Apple-style-span" style="font-family: arial; font-size: small; ">"</span></span></div>
<div><br></div><div>Can a plugin ever call into a script while a script is running besides when the script is making a synchronous call to the plugin? If so, that worries me since it'd be a way for the script to lose its lock at _any_ time.</div>
</div></div>