On Fri, Apr 3, 2009 at 2:49 PM, Robert O'Callahan <rob...@ocallahan.org>wrote:
> On Sat, Apr 4, 2009 at 6:35 AM, Jeremy Orlow <jor...@google.com> wrote: > >> If I understood the discussion correctly, the spec for document.cookie >> never stated anything about it being immutable while a script is running. > > > Well, there never was a decent spec for document.cookie for most of its > life, and even if there had been, no implementations allowed asynchronous > changes to cookies while a script was running (except for maybe during > alert()) and no-one really thought about it. Was this even identified as a > possible issue during Chrome development? > In addition to alert(), don't forget about all the great state changing things that can happen to the cookie database (and other data stores) during a synchronous XMLHttpRequest (or synchronous document.load) in Firefox. Maybe those are just bugs? What if a Firefox extension wants to muck around with the cookie database while a web page is blocked on a synchronous XMLHttpRequest? Maybe that should fail to avoid dead-locking? Sounds like a recipe for flaky extensions since it is unlikely that the extension author would have been prepared for being called at this time when access to the cookie database would have to be denied. (In Firefox, a new event loop is run to continue processing events while that synchronous XMLHttpRequest is active. That event loop helps keep the application alive and responsive to user action.) When deciding how to handle cookies in Chrome, we did not worry about the problem being debated here. Our concerns were allayed by recognizing that IE does not try to solve it (and IE6 is multi-process just like Chrome with a shared network stack), so clearly web developers must already have to cope. We flirted with the idea of letting each renderer maintain a local copy of its cookies, but that turned out to more complicated than was necessary. In the end, we ended up synchronizing with the main process on each call to document.cookie to fetch a snapshot. I think it would be best to specify that document.cookie returns a snapshot. I think that is consistent with existing implementations including IE, Firefox, and Chrome. I don't know about Safari and Opera, but it seems plausible that they could have similar behavior thanks to nested event queues which are typically used to support synchronous XHR and window.alert(). You would be surprised by the number of times it comes up that web developers at Google think Firefox has multi-threaded JS thanks to this behavior of synchronous XHR ;-) -Darin > > > People are now talking about specifying this, but there's been push back. >> Also, there's no way to guarantee serializability for the network traffic >> portion so I'm guessing (hoping!) that this wouldn't be required in the >> JavaScript side, even if it went through. > > > What exactly do you mean by that? It's easy to guarantee that reading the > cookies to send with an HTTP request is an atomic operation, and writing > them as a result of an HTTP response is an atomic operation. > > The spec is written in such a way that you can't have more that one event >> loop per browser window/worker, and everything is essentially tied to this >> one event loop. In other words, each window/worker can't run on more than >> one CPU core at a time. Thus, the only way for a web application to scale >> in todays world is going to be through additional windows and/or workers. >> > > Depending on exactly what you mean by a "Web application", that's not > really true. There are a variety of ways to exploit multicore parallelism > within a window with the current set of specs, at least in principle. > > Rob > -- > "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] >
