After having talked with Alex Crichton, my understanding is that it's not possible to use IPC channels with Tokio in their current form.
To make IPC channels usable with Tokio, we'd have to take whatever low level IO primitive IPC channels use under the hood, and then reimplement the same logic that the existing IPC channels implement on top of this, but using a streams based API (by streams, I mean the streams from the futures-rs, crate). I'm not quite sure how much work this would be, since I don't know how complex ipc channels are under the hood. In any case, I am skeptical that this is worth the effort, just so that we can use futures in the IPC client. Perhaps we should just rethink the client API so that it doesn't use futures at all. On Wed, Nov 16, 2016 at 2:47 PM, David Teller <dtel...@mozilla.com> wrote: > 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 > _______________________________________________ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
