On 1/12/15 2:39 PM, Josh Matthews wrote:
the obvious downside is that a tab's event loop will be cluttered with
constant attempts to poll for incomplete network responses during page
load.
Not just during page load. I expect this to peg the event loop on any
site that uses long polling (see
<http://en.wikipedia.org/wiki/Push_technology#Long_polling>) and other
Comet (<http://en.wikipedia.org/wiki/Comet_%28programming%29>)
techniques. Also anything that uses websockets or server push, if those
are implemented on top of this pull network infrastructure.
Some general thoughts on what consumers might want:
1) Gecko currently has an incremental consumer for HTML parsing,
non-incremental ones (buffer up all the data before acting) for CSS and
script. Not sure about imagelib.
2) In Gecko, the JS folks want to make the script consumer incremental
so they can kick off syntax parsing (or a full compile in the case of
asm.js) in parallel with the network load.
3) In general, the more you're doing stuff on multiple threads the more
it makes sense to do work on the results of a network load
(optimistically?) in parallel with the network load.... For example, if
Gecko's charset converters could run off the main thread, I would
totally be experimenting with doing streaming charset conversion for
scripts and stylesheets as the data comes in, even if our consumption of
the resulting Unicode remains non-incremental.
4) Blocking on network is a smell to me unless every single network
request lives in a separate task. Then it might make sense for cases
that don't need incremental consumption.
-Boris
_______________________________________________
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo
