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 <j...@joshmatthews.net>
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
