[pulseaudio-discuss] Module unloading in reverse order?

[David Henningsson]

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