On Tue, Sep 8, 2009 at 5:54 PM, Aaron Boodman <span dir="ltr"><<a href="mailto:aa@google.com">aa@google.com</a>></span> wrote:<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">
> You'd have to implement it via a mutex.<br>
<br>
</div>I think you would have a queue of all pending requests for access to<br>
storage, along with their associated callbacks, message loops, and<br>
execution environments. Each time the local storage frees up, if there<br>
is any queued request, invoke the callback in the correct environment. </blockquote><div><br></div><div>I guess I should have said "mutex" (in quotes) because something like this is what I intended.</div><div><br>
</div><div>Not that it matters to the spec, but this is more or less how I'm implementing locking within Chromium. The only difference is that the queue is of renderer processes (blocked on getting the lock) rather than individual callbacks. Doing the latter would be nice since sometimes web pages have to share the same process (and thus one origin may block another from executing because of Chromium implementational details).</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">> An optimized implementation could<br>
> wait until the first operation that can't be un-done before acquiring it,<br>
> and do everything optimistically until then. This is the same situation as<br>
> WebDatabase if I understand it correctly.<br>
<br>
</div>You can't do this because upgrading the lock could block the UI<br>
thread. Same thing with the database spec.<br></blockquote><div><br></div><div>Sure you could block the UI thread more, but there's nothing to stop you from doing a 'while (true) { }' inside the callback, which will block the UI thread as well. So I disagree with your assertion that waiting for a lock upgrade is a deal breaker. I don't think any implementation is realistically going to do anything like this in the near term, though.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">If you want to get fancy, the transaction() method can take a<br>
read/write param. This is what the database spec does, but I think it<br>
is overkill here, personally.</blockquote><div><br></div><div>Agreed.</div><div><br></div><div><br></div><div>On Tue, Sep 8, 2009 at 6:02 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 Tue, Sep 8, 2009 at 8:38 PM, Jeremy Orlow <span dir="ltr"><<a href="mailto:jorlow@chromium.org" target="_blank">jorlow@chromium.org</a>></span> wrote:<br><div class="gmail_quote"><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 class="gmail_quote"><div><div></div>To be clear, Chrome is not going to implement the storage mutex with respect to cookies, but we are going to implement it for LocalStorage. Because of this, we can handle the localStorage mutex on a per-origin basis (which I'm implementing right now).<br clear="all">
</div></div></blockquote></div><br></div>Looking back over previous threads on the storage mutex, I can't seem to remember or find the reason that implementing the storage mutex for cookies can't easily be done with a mutex per domain. Ian pointed out this approach breaks if you can make synchronous script calls across origins (e.g. across IFRAME boundaries), but can you actually make such calls? Or if you can (NPAPI?), can we just declare that those APIs release the storage mutex?<br>
</blockquote><div><br></div><div>I thought it over, but I can't come up with any deadlock scenario. I would still be a bit worried about performance issues (including many ways a developer could shoot themself in the foot), but it is an interesting idea.</div>
<div> </div><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; ">
I know that setting document.domain makes this tricky because it synchronously enables new cross-domain interactions, but can't we handle that by declaring that setting document.domain releases the storage mutex?</blockquote>
<div><br></div><div>I think this would be very reasonable. Especially with all the other things that already implicitly drop the lock.</div></div></div>