This allows closures to be properly unrefed when they are no longer
used instead of staying alive until wireplumber exits
Because GClosure has no weak references, we are now sharing the
GPtrArray that holds these references among all the active closures
and each closure is responsible for removing itself from the array
when it is finalized. The lua engine holds a reference to a "store"
object that also has a pointer to the array and when this "store"
is finalized, all closures are invalidated and removed. Even if they
stay alive afterwards, they are only holding a ref to an empty array
This is mainly for security reasons. This way, we can limit the
permissions of wpexec without limiting wireplumber, for instance
with pipewire's default module-access, which limits apps based on
their executable name
This function loads and enables "api" plugins and makes them
available in the specified callback. This is intended to be used
by interactive scripts in order to get access to "api" plugins
such as the new "default-nodes-api" and "mixer-api"
This module provides an API to get/set volume controls on nodes,
using the same logic as pipewire-pulse, which means it will use
the device Route props when a node is associated with a device
that has this capability
The main problem observed is when a link that is owned by a WpLink
is removed from the server because one of the linked nodes is gone.
This would cause the APPEARS_ON_REGISTRY flag to go away but the
WpGlobal would still remain in the globals list...
To fix this, forcibly remove the global from the globals list when
it is removed from the registry, even if it is still owned by some
proxy. The proxy at that point is unable to function anyway, because
we make sure to destroy the pw_proxy by removing FEATURE_BOUND when
the global is removed from the registry.
Additionally, ref global->proxy before removing FEATURE_BOUND to
prevent crashing. If the proxy owns the global and the pw-proxy-destroyed
signal causes whoever owns the proxy to drop his reference, _deactivate()
will crash because no-one will be holding a ref to the proxy.
The assumption about the global id in wp_registry_prepare_new_global()
was not valid because this function may also be called from the proxy
bound event and this may be before the registry has signalled the
removal of an old global with the same id, for instance
We should instead check this at the point where we expose the global.
If the assertion doesn't hold at that point, we are going to leak an
old WpGlobal, so we must ensure it.
