Re: [dev-servo] Per-document event queues
Partially related question: are there plans for per-add-on event queue? On 21/07/15 16:31, Josh Matthews wrote: We currently have a model where each eTLD has a separate event queue. This is an improvement over Gecko (one event queue to rule them all), but I suspect we can do better. Specifically, I'm interested in moving to isolated event queues per document, then doing round-robin event processing on each on in an eTLD group. That would make the script event loop look something like this: -- David Rajchenbach-Teller, PhD Performance Team, Mozilla signature.asc Description: OpenPGP digital signature ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Per-document event queues
I don't believe anybody has put thought into addons beyond something like Chrome at this point. On 2015-07-23 6:05 PM, David Rajchenbach-Teller wrote: Partially related question: are there plans for per-add-on event queue? On 21/07/15 16:31, Josh Matthews wrote: We currently have a model where each eTLD has a separate event queue. This is an improvement over Gecko (one event queue to rule them all), but I suspect we can do better. Specifically, I'm interested in moving to isolated event queues per document, then doing round-robin event processing on each on in an eTLD group. That would make the script event loop look something like this: ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Per-document event queues
On Fri, Jul 24, 2015 at 10:26 AM, Josh Matthews j...@joshmatthews.net wrote: I don't believe anybody has put thought into addons beyond something like Chrome at this point. FWIW https://bugzilla.mozilla.org/show_bug.cgi?id=1161828 Rob -- lbir ye,ea yer.tnietoehr rdn rdsme,anea lurpr edna e hnysnenh hhe uresyf toD selthor stor edna siewaoeodm or v sstvr esBa kbvted,t rdsme,aoreseoouoto o l euetiuruewFa kbn e hnystoivateweh uresyf tulsa rehr rdm or rnea lurpr .a war hsrer holsa rodvted,t nenh hneireseoouot.tniesiewaoeivatewt sstvr esn ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Per-document event queues
On 21/07/15 15:31, Josh Matthews wrote: This appears to satisfy the requirements of the spec (c.f. https://html.spec.whatwg.org/multipage/webappapis.html#processing-model-9 https://html.spec.whatwg.org/multipage/webappapis.html#task-source). My main concern is the loss of deterministic ordering here - with a single event queue, any event that is queued before another is guaranteed to run before it as well. In this new model, if two events are added to different queues in the same document, they could run in any order. This could be fixed by always running the oldest event available in any single document's queue, but are there dangers of out-of-order events between same-origin documents? Thoughts? Per the conversation we had on irc, I think that the spec allows the current model but not your proposed design (see [1]). I believe the proposed model has observable changes that likely have a compat. impact e.g. given a page with two subframes A and B, a script on the parent that does A.postMessage(1); A.postMessage(2); B.postMessage(3) can currently rely on the messages being received in the order 1,2,3 whereas that is not a possible ordering in the event-loop-per-document design. Therefore my initial reaction is that this is unlikely to work. However it might be worthwhile checking what IE does here as I vaugely remember they have relatively well-isolated iframes (but it's several years since I tested it, so I don't remember any details). [1] https://html.spec.whatwg.org/multipage/webappapis.html#event-loop (There must be at least one browsing context event loop per user agent, and at most one per unit of related similar-origin browsing contexts.) ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
[dev-servo] Per-document event queues
We currently have a model where each eTLD has a separate event queue.
This is an improvement over Gecko (one event queue to rule them all),
but I suspect we can do better. Specifically, I'm interested in moving
to isolated event queues per document, then doing round-robin event
processing on each on in an eTLD group. That would make the script event
loop look something like this:
enum ScriptMsg {
AttachDocument(OptionParentInfo, DocumentInfo),
DetachDocument(DocumentInfo),
InputEvent(EventData),
...
}
struct ScriptTask {
// all documents currently residing in memory for this eTLD
documents: HashMapPipelineId, JSDocument,
// queue for events that cannot be processed by a single document
eTLD_control_port: ReceiverScriptMsg,
// documents that still require a chance to run events
not_yet_processed: VecPipelineId,
}
impl ScriptTask {
fn run(mut self) {
loop {
self.run_one_event();
// simple round-robin event processing
if self.not_yet_processed.is_empty() {
self.not_yet_processed = self.documents.keys().collect();
}
let current = self.not_yet_processed.pop();
let document = documents.get(current);
if !document.should_run_events() {
continue;
}
document.run_one_event();
}
}
fn run_one_event(mut self) {
// process a single event if it is available
if let Ok(msg) = self.eTLD_control_port.try_recv() {
match msg {
InputEvent(data) = {
// let document be the appropriate target for the event
document.queue_user_input(data);
}
...
}
}
}
}
struct Document {
network_task_source: ReceiverNetworkMsg,
timer_task_source: ReceiverTimerMsg,
user_input_task_source: ReceiverUserInputMsg,
history_traversal_task_source: ReceiverHistoryTraversalMsg,
dom_manipulation_task_source: ReceiverDOMManipulationMsg,
}
impl Document {
fn should_run_events(mut self) {
// can choose to throttle events (eg. every 1/N), or not run them
at all
}
fn run_one_event(mut self) {
// This could also be a more complicated decision to prioritize
user input, for example.
select! {
msg = self.network_task_source.try_recv() =
self.process_network_task(msg),
msg = self.timer_task_source.try_recv() =
self.process_timer_task(msg),
// ...
}
}
}
This appears to satisfy the requirements of the spec (c.f.
https://html.spec.whatwg.org/multipage/webappapis.html#processing-model-9
https://html.spec.whatwg.org/multipage/webappapis.html#task-source). My
main concern is the loss of deterministic ordering here - with a single
event queue, any event that is queued before another is guaranteed to
run before it as well. In this new model, if two events are added to
different queues in the same document, they could run in any order. This
could be fixed by always running the oldest event available in any
single document's queue, but are there dangers of out-of-order events
between same-origin documents? Thoughts?
Cheers,
Josh
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo
