[dev-servo] Channels and synchronous networking
I started prototyping the async networking redesign. To make the up-front work easier, I've added a layer of abstraction so consumers can opt-in to receiving async replies so I don't need to rewrite everything all at once. This has led me to a discovery - our current implementation of sync XHR works really well (spec-compliant, even!) using channels, and we'll need to introduce something like nested event loops if we insist on switching wholesale to async events for all consumers. This is something that I would _really_ like to avoid doing. Patrick, I know you've been keen on the network rewrite eliminating the pattern of sending channels over channels. How bad would it be if we kept this capability but barely made use of it? Cheers, Josh ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Channels and synchronous networking
On Tue, Jan 27, 2015 at 10:10 PM, Josh Matthews wrote: > I started prototyping the async networking redesign. To make the up-front > work easier, I've added a layer of abstraction so consumers can opt-in to > receiving async replies so I don't need to rewrite everything all at once. > This has led me to a discovery - our current implementation of sync XHR > works really well (spec-compliant, even!) using channels, and we'll need to > introduce something like nested event loops if we insist on switching > wholesale to async events for all consumers. This is something that I would > _really_ like to avoid doing. > > Patrick, I know you've been keen on the network rewrite eliminating the > pattern of sending channels over channels. How bad would it be if we kept > this capability but barely made use of it? > > Cheers, > Josh > ___ > dev-servo mailing list > dev-servo@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-servo > I'm not really sure what servo's event loop architecture looks like, but one of the things we'd love to do with Gecko but would require tremendous effort at this point is split the event queue per window/document/something. Then we'd implement sync XHR by just blocking the relevant queue and continuing to process messages via a scheduler. If you have the opportunity to build something similar in from the beginning you should strongly consider taking it. - Kyle ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Channels and synchronous networking
We don't have the notion of a global event loop or anything. We effectively have an event loop per script task (ie. event loop per TLD), but no ability to spin it arbitrarily at the moment. The benefit of using channels for some forms of communication is that they side-step the event loop and can form their own limited protocols that enable synchronous communication. On 2015-01-27 9:51 PM, Kyle Huey wrote: On Tue, Jan 27, 2015 at 10:10 PM, Josh Matthews wrote: I started prototyping the async networking redesign. To make the up-front work easier, I've added a layer of abstraction so consumers can opt-in to receiving async replies so I don't need to rewrite everything all at once. This has led me to a discovery - our current implementation of sync XHR works really well (spec-compliant, even!) using channels, and we'll need to introduce something like nested event loops if we insist on switching wholesale to async events for all consumers. This is something that I would _really_ like to avoid doing. Patrick, I know you've been keen on the network rewrite eliminating the pattern of sending channels over channels. How bad would it be if we kept this capability but barely made use of it? Cheers, Josh ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo I'm not really sure what servo's event loop architecture looks like, but one of the things we'd love to do with Gecko but would require tremendous effort at this point is split the event queue per window/document/something. Then we'd implement sync XHR by just blocking the relevant queue and continuing to process messages via a scheduler. If you have the opportunity to build something similar in from the beginning you should strongly consider taking it. - Kyle ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
[dev-servo] Rust upgrade has landed
Tree is open. Review/rebase all the things; there's some backlog in the PR queue. ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
[dev-servo] vsync integration
Caspy7 in #servo pointed me towards an explanation of new vsync integration in Gecko: http://www.masonchang.com/blog/2015/1/22/project-silk . How's Servo stack up against the state of the art here? ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Channels and synchronous networking
On 1/27/15 5:46 PM, Josh Matthews wrote: We don't have the notion of a global event loop or anything. We effectively have an event loop per script task (ie. event loop per TLD), but no ability to spin it arbitrarily at the moment. How do you plan to implement alert()? Do you plan to allow an alert model like Firefox, where the alert doesn't freeze the entire UI? Realistically, I think you actually want multiple event queues even per script task (akin to the task queues in the HTML spec) and the ability to selectively shut them off temporarily... -Boris ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
