[whatwg] Worker feedback

[Robert O'Callahan]

On Sat, Apr 4, 2009 at 11:17 AM, Jeremy Orlow <jorlow at google.com> wrote:

> True serializability would imply that the HTTP request read and write are
> atomic.  In other words, you'd have to keep a lock for the entirety of each
> HTTP request and couldn't do multiple in parallel.  When I said there's no
> way to guarantee serializability, I guess I meant to qualify it with "in
> practice".
>

OK, I don't think anyone expects, wants, or has ever had that :-).

After thinking about it for a bit, your suggestion of "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" does seems like a pretty
> sensible compromise.
>

It's what the spec says (the spec doesn't say anything about reading cookies
when constructing an HTTP request, but that's probably just an oversight)
and it's what I expected, so not really a compromise :-).

The one thing I'd still be concerned about:  localStorage separates storage
> space by origins.  In other words, www.google.com cannot access
> localStorage values from google.com and visa versa.  Cookies, on the other
> hand, have a much more complex scheme of access control.  Coming up with an
> efficient and dead-lock-proof locking scheme might take some careful
> thought.
>

I hope browser implementors can solve this internally. I think the main
thing we have to watch out for in the spec is situations where a script can
*synchronously* "entangle" browsing contexts that previously could not
interfere with each other (i.e., that a browser could have assigned
independent locks). (Setting document.domain might be a problem, for
example, although I don't know enough about cookies to be sure.)


>
>> 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.
>
>
> What else is there?  (I believe you, I'm just interested in knowing what's
> out there.)
>

In Gecko we're working on making HTML parsing happen in parallel with other
activities (including script execution), and video decoding already does. I
can imagine doing all graphics rendering in parallel with other tasks and
being parallel internally too. Some aspects of layout can be parallelized
internally and overlapped with script execution. Expensive Javascript
compiler optimizations can be run in parallel with actual application work.
Canvas3D can run GPU programs which are another form of parallelism (OK
that's not exactly "multicore parallelism" unless you believe Intel).

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]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090404/b5c4328f/attachment-0002.htm>