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
