That does suggest either going with 2.1 (push-based, transient data in
runnables) or 2.3 (push-based, shared memory).
On 2015-01-14 1:00 PM, Patrick Walton wrote:
One important thing to consider is that in order to be multiprocess-safe we
cannot be passing around channels. Instead we need to either (a) use
request IDs and stream everything over one (or a small number of) file
descriptors or (b) pass file descriptors over IPC using the OS-specific
APIs in order to stream content back. The current resource task
infrastructure uses many Rust ports and channels, so I am unable to sandbox
Servo at present. Since the current resource task infrastructure needs to
be rewritten anyway, this is a good opportunity to fix our security story
here.
On Mon, Jan 12, 2015 at 7:13 PM, Boris Zbarsky <bzbar...@mit.edu> wrote:
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
_______________________________________________
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo
