[dev-servo] Using IPC channels with Tokio?
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
Re: [dev-servo] Using IPC channels with Tokio?
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
Re: [dev-servo] Using IPC channels with Tokio?
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 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
