<div class="gmail_quote">On Fri, Sep 4, 2009 at 5:53 PM, Anne van Kesteren <span dir="ltr"><<a href="mailto:annevk@opera.com">annevk@opera.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

On Fri, 04 Sep 2009 09:02:45 +0200, Chris Jones <<a href="mailto:cjones@mozilla.com" target="_blank">cjones@mozilla.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Feedback very much desired.<br>
</blockquote>
<br>
I'm not really sure what to say other than that I'm not at all a fan of a change that breaks existing deployments. I thought that was a pretty clear outcome from last time we went about this. I also thought it was pretty clear we wanted the burden to be on user agents. (I also recall, but am not a 100% sure, that developers from Mozilla agreed to this, even though it would be hard to make it all work in Gecko.)<br>

</blockquote></div><font class="Apple-style-span" color="#888888"><br></font><div>I believe this opinion was expressed by people who hadn't yet tried to do it in a web browser with multiple event loops.  :-)</div><div>

<br></div><div>A bunch of us working on Chromium have spent a lot of time thinking about this and I don't think it's just a matter of burdening user agents.  I think it's pretty clear that the spec, as is, is not possible to implement without making it trivial for a single website to lock up all of your event loops....which is a major step back in terms of browser performance...especially in this multi-core world we now live in.  :-)</div>

<div><br></div><div>This is especially true if the storage mutex extends to cookies since one tab running a poorly written site can lock everything up.  And it sounds like, because of that, no one is going to implement the storage mutex for cookies per the spec.  I really do think it's time to discuss alternatives.</div>