On Tue, Mar 31, 2009 at 7:22 AM, Drew Wilson <span dir="ltr"><<a href="mailto:atwilson@google.com">atwilson@google.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="gmail_quote">
<div> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">Re: cookies<div class="im"><br>
I suppose that network activity should also wait for the lock. I've made<br>
that happen.<br>
</div></blockquote><div><br></div><div>Seems like that would restrict parallelism between network loads and executing javascript, which seems like the wrong direction to go.</div><div><br></div><div>It feels like we are jumping through hoops to protect running script from having document.cookies modified out from underneath it, and now some of the ramifications may have real performance impacts. From a pragmatic point of view, I just want to remind people that many current browsers do not make these types of guarantees about document.cookies, and yet the tubes have not imploded.</div>
</div></blockquote><div><br>We have no way of knowing how much trouble this has caused so far; non-reproducibility means you probably won't get a good bug report for any given incident.<br><br>It's even plausible that people are getting lucky with cookie races almost all the time, or maybe cookies are usually used in a way that makes them a non-issue. That doesn't mean designing cookie races in is a good idea.<br>
<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="gmail_quote"><div></div><div class="im">
<div> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">> Cookies have a cross-domain aspect (multiple subdomains can share cookie<br>
> state at the top domain) - does this impact the specification of the<br>
> storage mutex since we need to lockout multiple domains?<br>
<br>
There's only one lock, so that should work fine.<br>
</blockquote><div><br></div></div><div>OK, I was assuming a single per-domain lock (ala localStorage) but it sounds like there's a group lock, cross-domain. This makes it even more onerous if network activity across all related domains has to serialize on a single lock. </div>
</div></blockquote><div><br>It doesn't have to. There are lots of ways to optimize here.<br clear="all"><br></div></div>Rob<br>-- <br>"He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all." [Isaiah 53:5-6]<br>