D-Bus is killing me

[Mystilleef]

> > 3). D-Bus Isn't re-entrant.
> >
> > Because D-Bus isn't re-entrant, I have to split my application into
> > a client-server model. The server exposes public methods and signals,
> > while the client calls them. This means my application has to maintain
> > two processes.
>
> Is there a particular reason you need to use D-Bus for the internal
> API? Given all the pain it causes, implementing an internal API that
> both the public D-Bus interface and the client functionality uses
> sounds like a good idea (but then again, I only saw the difficulties
> in this message, not the goals...).

My application, a text editor, can spawn multiple instances of itself.
I use D-Bus to ensure all instances use the same process. I also use
D-Bus for inter-instance communication. For example, via D-Bus I can
show users all open documents, and allow them to manipulate the
documents (e.g close a specific document, focus a specific document
window, close all running instances, switch quickly between documents etc).
Perhaps my D-Bus usage is unconventional and uncommon. All these work
for the most part, but they can be unreliable. For example, when stress
testing my application I quickly realized, D-Bus begins to error out
(or crash, can't remember) after spawning a hundred instances of my
application. Nobody is going to create 100 instances of my application, but
still. Another problem I had is that instances of my application
were still responding to signals, even after they were no longer in
use. Exceptions would occur followed by an explosion of the whole system.
Well this is largely a weirdness with Python (GC/object destruction and
what have you). I have the same problem with GObject objects. But
GObject has a way to disconnect signals. Is there a way to disconnect
D-Bus signals, like in GObject?