[Metabug] Plugins should not be able to block main UI

[Chris Halse Rogers]

We've had all sorts of problems with plugins blocking (or deadlocking) Do. Here's a metabug to track the problem and ideas for solving it. I'll target it at 0.7. We can break plugin ABI as much as we like, since we'll likely be doing it anyway, and I don't think we should be hesitant to break the API, too.

I'll start:
a) Spooling all plugin operations out to threads. This has the obvious problem that GTK isn't threadsafe, and this can cause problems. That said, GLib itself is (or claims to be) threadsafe - is there any reason why plugins need to be using GTK outside of the configuration dialog?

[Chris Halse Rogers (raof)]

Actually, it seems to have occured to a number of people that there's nothing that plugins do that's on Do's critical performance path. As such, it seems like we could enforce process separation between plugins and core, at least for the vast majority of plugins (live searching plugins may want to/need to remain in core's address space for performance).

This immediately and completely solves a couple of our big problems - namely, plugins deadlocking Do and plugins crashing Do. It moves from an impossible problem to one of input validation in core + a much less annoying problem involving solely plugins.

Presumably this would be implemented as a dbus interface on core + a new plugin loader binary.