remote: handle IPC on Windows

[grovesNL]

We need to consider some options to support IPC on Windows. The crate which is currently being used https://github.com/servo/ipc-channel states in the README that Windows is not supported yet.

Relevant PRs/issues:
servo/ipc-channel#166
servo/ipc-channel#108
servo/ipc-channel#118

[kvark]

Alternatives:

• https://crates.io/crates/sandbox-ipc
• https://crates.io/crates/ipc

cc @JohnColanduoni

[JohnColanduoni]

sandbox-ipc indeed has Windows support, but it as of yet doesn't have a way to safely send kernel resources (file handles, sockets, etc.) from a less privileged process to a more/equal privileged one (it has to do with a lack of granularity to handle duplication rights). There are ways to work around this via having a more privileged process to act as a sort of "escrow" agent, but I've not yet implemented it.

If you don't need to do that, and it's fine doing all IPC through Tokio, it should suffice as is. I've run into some performance/scheduling limitations due to Tokio/Windows impedance mismatches and am halfway through a solution, but the performance may already be sufficient for your needs. I'm also moving the MacOS implementation to use mach IPC like ipc-channel does as part of the same rework, if that's a consideration (IOSurfaces for example cannot be passed via the current socketpair implementation, which could be useful for WebGPU).

[kvark]

Another thing - https://github.com/NikVolf/parity-tokio-ipc

@JohnColanduoni

it's fine doing all IPC through Tokio

Could you clarify how this would be done? Perhaps, point me to an example, if possible.

[kvark]

I finished the round of investigations on IPC. We are going to use Gecko's standard IPC mechanism called IPDL. The client side will be serializing commands and data into a raw Vec<u8> using Rust code, which is sent over the IPC and then decoded by the server bit of Rust code.

The good news is that this is precisely what WebRender does today! So we aren't going to invent new ways of IPC communication, and any follow-up improvements to Gecko infrastructure would benefit us automatically.

As for the wgpu-remote responsibilities, it will need to provide that serialization/deserialization code and communicate to wgpu-native more closely than the native WebGPU API allows. The wgpu-remote crate would have no IPC mechanisms in itself. I'm open to renaming it to something like wgpu-ipc.

I'll be prototyping this solution shortly in Gecko and follow-up with the code changes here.