At a high level, it seems reasonable, but I don't have a good grasp over what kinds of messages are going over these channels and with what frequency. That seems to be crucial with respect to judging the perf effects of moving to a serialization scheme.
Niko On Fri, Nov 01, 2013 at 10:54:32PM -0700, Patrick Walton wrote: > Hi everyone, > > Currently Servo's event loop is a poll model on a fixed timer. This > is done for historical reasons: originally the Rust runtime did not > interoperate very well with native UI event loops and we had no > choice. This is very bad—it precludes putting the browser engine into > production for countless reasons and actually hinders our results > when comparing performance against other engines because the polling > chews CPU that could be used for other things. And, as we know with > Gecko, event loop technical debt accumulates interest very rapidly. > So I'd like to fix this soon. > > After talking some with Alex Crichton, who has been responsible for > much of the modern Rust I/O library, I think that there's a > reasonable path forward that also dovetails quite nicely with the > plans for multi-process Servo. Specifically, these are the steps I'm > considering: > > 1. Enforce the `Encodable` bound on the compositor-to-renderer > messages, adding serialization implementations where necessary. This > is much easier in Rust than in C++ because (a) the compiler tells you > where you need the implementations; (b) with the `deriving` feature > the compiler will auto-generate the necessary serialization code for > most data types for you. (Unlike slow reflection-based systems, the > automatic serialization mechanism of Rust is based on generating > highly optimized code at compile time, so it should be fast enough > for our purposes.) > > 2. Change the compositor-to-renderer protocol to run over a local > Unix socket instead of a Rust pipe. Because Unix sockets are > integrated into `libuv` and the Rust standard library now has > idiomatic bindings for them, this should be fairly straightforward. > (When we do a Windows port this will be replaced with Windows' > equivalent; I think `libuv` supports Windows Named Pipes or > whatever.) > > 3. Attach the file descriptor for the compositor's end of the pipe to > the compositor event loop, and eliminate the polling. > > Thus at the end of this, the renderer end of the Unix socket will be > in `libuv` land, and the compositor end will be in the OS's native > event loop. > > The interesting thing about this approach is that we take out two > problems in one fell swoop: the event loop integration issue and the > multiprocess/sandboxing issue. The remaining issues for sandboxing > are (a) adding the code to spawn the processes, which will probably > want Rust code; (b) actually dropping into the sandbox; (c) figuring > out what we want to do with GL, which is probably "don't worry about > it for now". > > Does this sound reasonable to everyone? > > Patrick > _______________________________________________ > 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
