Having worked on e10s, just a quick note on multi-process: it is really important to make the default use of IPC resilient to communication problems, in particular the other process not responding correctly, because it has crashed, frozen or is otherwise too busy. In Firefox, e10s fails to provide this and the result is very fragile.
So whichever tool you use for this, please make sure that the API encourages the correct behavior. Cheers, David On 16/11/16 14:16, Eddy Bruel wrote: > For the Servo debugger, now that we've begun landing the Rust interface to > the Debugger API, we can also started working on the next step, which is an > IPC client/server on top of that Rust interface. This IPC server will allow > the main debugger server, which lives in a separate process, to talk to the > debugger API of one or more script threads. > > Since the IPC client/server inherently asynchronous in nature, I was hoping > to implement the client side API with futures. Essentially, for each > synchronous function on the server side, there will be a corresponding > asynchronous function on the client side that returns a future. > > The futures on the client side will typically be resolved when we receive a > message from an IPC channel (which will typically be either a reply to a > pending request, or some kind of notification). For that to work, we need > to be able to hook IPC channels into a Tokio event loop. > > Given the above, I wondered if there is currently any support for using IPC > channels with Tokio? And if not, would it be possible to implement this? > _______________________________________________ > 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
