[pulseaudio-discuss] Module unloading in reverse order?

[Tanu Kaskinen]

On Fri, 2012-01-27 at 13:06 +0100, David Henningsson wrote:
> I agree with everything you say above; just want to add that even if 
> unloading modules in any order should work, one way can be more optimal 
> than the other.
> 
> Imagine a dbus protocol module (I don't know if the existing one works 
> this way), that on unload could send a removal request to remove 
> org.pulseaudio.* from the bus, but if module-udev-detect is unloaded 
> before, will have to send several requests to remove 
> org.pulseaudio.card0, org.pulseaudio.card1, org.pulseaudio.sink0, 
> org.pulseaudio.sink1, and so on, and that will be less optimal.

Good point. Unregistering objects from the bus isn't a problem, because
objects aren't registered in the bus in the first place (that's not how
D-Bus works), and we don't use a bus anyway, but the concern is valid
with signals: if module-udev-detect is unloaded first,
module-dbus-protocol will send a bunch of signals (SinkRemoved etc.) to
the clients, which could be avoided by unloading module-dbus-protocol
first.

An optimization could be added to module-dbus-protocol that would
inhibit signal emission while unloading the daemon, but just changing
the module unloading order would quite effectively remove the need for
these optimizations when using the default configuration. Therefore, my
preference has now changed to reversing the module unloading order
before starting to add various checks about the daemon status to
multiple modules.

-- 
Tanu