team-phoenix / Phoenix

A multi-system emulator and library manager designed to be both powerful and easy to use.
http://phoenix.vg
GNU General Public License v2.0
377 stars 39 forks source link

Backend as a separate process (sandboxing) #314

Open athairus opened 7 years ago

athairus commented 7 years ago

With no way to have multiple Libretro cores at once in a single address space and the fact the Libretro cores are free to do all kinds of bad things that can tank the program that we don't have much control over (calling abort(), accessing null pointers, etc.) it might be worth looking into making the backend a separate process. From there we can more or less act as a debugger to this child process. We can catch program-terminating signals and possibly read process memory directly to recover save data if we know the process is in an inconsistent state.

Qt has an API for pipes: http://doc.qt.io/qt-5/qlocalsocket.html

The interface between Phoenix and the external process will probably be input and control signals to the process and audio/video data from. This might get hairy with OpenGL as we'll end up copying completed frames from VRAM to RAM (only to end up back in VRAM when composited into the QML scene).

One thing that is a really nice advantage of this approach is we can launch as many of these instances as we want. The live preview idea lives on!

This shouldn't mean much to GStreamer other than adding a bit more complexity. GStreamer already has the ability to have multiple pipelines (TODO: make sure that's actually true). The GStreamer plugins aren't considered "external code" because we'll be writing them.

athairus commented 7 years ago

I've decided on a few tweaks:

athairus commented 7 years ago

IPC libraries: https://github.com/fffaraz/awesome-cpp#inter-process-communication IPC benchmarks: https://github.com/rigtorp/ipc-bench