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
_______________________________________________
pulseaudio-discuss mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
