On 01/27/2012 12:48 PM, Tanu Kaskinen wrote: > On Fri, 2012-01-27 at 10:28 +0100, David Henningsson wrote: >> I've noticed that modules unload in the same order that they are >> created: i e, if module A loads first, and then module B, then module A >> is also unloaded before module B when pulseaudio is shutting down. >> >> It feels more logical to me to have it the other way around, like a >> "module stack", so if module A is loaded first, it should be unloaded last. >> >> Now, if you agree with me, dare we switch this around? It would at least >> lead to that there is no module-null-sink loaded at shutdown ( \o/ ), >> and maybe unloading module-dbus-protocol before module-udev-detect would >> also reduce the risk of SIGSEGVs discovered yesterday. >> >> But there might be things I'm not seeing, so what do you think? > > I agree that it would make some sense to load the modules in a reverse > order (or I think you said it better: it "feels logical"). I would guess > that things are how they are because it was convenient to implement it > that way. It's not very simple to iterate through the module idxset in a > reverse order. > > In my opinion it should be safe to load and unload modules in what ever > order - if there are crashes resulting from unloading the modules in > certain order, the bug is not in the unloading order. So from that point > of view I don't see it as a big deal if the modules are unloaded in the > same order as they were loaded. > > The remaining question is what should be done about the null sink > getting loaded at shutdown. I would prefer changing module-always-sink > so that it doesn't load the null sink when the daemon is shutting down. > Still, if someone posts a patch that reverses the module unloading > order, I'd be fine with that too. 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. -- David Henningsson, Canonical Ltd. http://launchpad.net/~diwic
