It is possible that during this process some object managers emit
their "installed" signal, and it is possible that some object managers
are destroyed within the handler of this signal, ending up with a dangling
object manager pointer (since we do not ref object managers in the registry)
and with a modified object_managers list during iteration...
Related to: #534
A core sync is not really necessary here because whatever objects the remote
pipewire daemon has to announce have already been sent to us on a message
and this message is already being processed at this point. This means, we are
not going to be returning to the main loop until all the new objects have been
announced and therefore placed into the tmp globals array. So, we can also use
an idle callback and achieve the same effect of slightly delaying until all
new globals have been announced.
With an idle callback, we can be more agile and add those new objects immediately
after the message has been processed instead of waiting for a pw_core_sync()
reply, which will come in the next message.
This fixes an odd failure of the si-standard-link test after applying the fix
for #517, which was caused by the fact that the test was previously relying on
a delay caused by some unrelated globals being prepared in the object manager
that tries to verify the graph state. After those globals were removed from the
internal preparation queue, the test would fail to detect the link objects
because they were stuck in the tmp_globals array for too long.
With the previous check, any global matching either the type or the global
properties of the interest would be considered for inclusion in the object
manager and would be prepared only to fail the same check later.
The correct way to check is (variable & (X|Y) == (X|Y)), which is what
SPA_FLAG_IS_SET() expands to.
Fixes#517
This allows registering arbitrary objects on the core's registry and
finding them later, without having to add API for each and every object.
I think this is useful enough to have it public, even though it's
probably not going to be used that much... The rationale here is to
allow registering custom component loaders without having to make them
subclass WpPlugin or to create custom API for registering component
loaders specifically.
Also, remove the wp_plugin_register() and wp_si_factory_register()
functions, since they are not going to be used much in the future.
The idea is to let the component loader do the registration under the
scenes, as the component is getting loaded.
Each component can optionally "provide" a feature, which is basically
a string that describes the feature (ex. "support.dbus"). If the
component loads successfully, the feature is marked as provided and
can be tested for its presence with wp_core_test_feature()
The intention is to make checks for enabled log topics faster.
Every topic has its own structure that is statically defined in the file
where the logs are printed from. The structure is initialized transparently
when it is first used and it contains all the log level flags for the levels
that this topic should print messages. It is then checked on the wp_log()
macro before printing the message.
Topics from SPA/PipeWire are also handled natively, so messages are printed
directly without checking if the topic is enabled, since the PipeWire and SPA
macros do the checking themselves.
Messages coming from GLib are checked inside the handler.
An internal WpLogFields object is used to manage the state of each log
message, populating all the fields appropriately from the place they
are coming from (wp_log, spa_log, glib log), formatting the message and
then printing it. For printing to the journald, we still use the glib
message handler, converting all the needed fields to GLogField on demand.
That message handler does not do any checks for the topic or the level, so
we can just call it to send the message.
If a global is removed while an activation transition is in progress
and it happens that this activation transition was triggered by an
object manager, it is theoretically possible that this object manager
will then add this proxy after the transition completes, since
the transition is holding a ref on the proxy and therefore it will
not be destroyed. This ensures that the transitions are stopped on time
and the ref is dropped.
Because of this change, it is now also necessary to destroy the pw_proxy
on WpProxy's dispose() function, because if a proxy is removed before
it is bound, the registry aborts the activation but wp_proxy_deactivate()
is not destroying the proxy, since FEATURE_BOUND is not active.
In dispose() we can guarantee that the pw_proxy is destroyed.
Consider invalid id as removed marker, similarly as in the preceding for
loop. This condition should currently not be possible to hit in
practice, but better to clean up.
Once an object is removed from the registry, its id is invalidated and
can be later reused by other objects. WpGlobal objects may be
long-lived: e.g. those in tmp_globals may live over an add,remove,add
sequence for the same id, and a new WpGlobal must be used for the second
add. However, currently e.g. wp_registry_prepare_new_global may pick the
WpGlobal for a previously removed object from the tmp_globals list.
To address this, invalidate the WpGlobal id immediately when we get the
registry remove event.
The idle callback may be called after the object manager has been
destroyed, or the object manager may be destroyed while emitting
one of the signals from the idle callback, so it needs to be ref'ed
while the callback is running. g_cclosure_new_object ensures that
in both cases the code behaves correctly.
Sometimes, especially when running the wireplumber daemon with valgrind, a new
global with the same Id as another old global owned by a proxy wants to be
exposed before the old proxy is destroyed. If this happens, instead of returning
with an assertion error, we remove the old global and we export the new one.
Until now, object manager could only match pw global properties on
pw global objects, because this is the only available properties set
at the time the registry creates the global.
With this change, the object manager will now bind the proxy
if the type and the pw global properties have matched and will wait
until the proxy is available with all of its properties and tries
the check again.
Also rename the intermediate lua api table WpDebug -> WpLog
Keeps things more consistent with the function names (wp_log*),
with the lua api (Log.*) and with pipewire using log.{h,c} as well.
After all, these functions are for logging...
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.
This is an attempt to unclutter the API of WpProxy and
split functionality into smaller pieces, making it easier
to work with.
In this new class layout, we have the following classes:
- WpObject: base class for everything; handles activating
| and deactivating "features"
|- WpProxy: base class for anything that wraps a pw_proxy;
| handles events from pw_proxy and nothing more
|- WpGlobalProxy: handles integration with the registry
All the other classes derive from WpGlobalProxy. The reason
for separating WpGlobalProxy from WpProxy, though, is that
classes such as WpImplNode / WpSpaDevice can also derive from
WpProxy now, without interfacing with the registry.
All objects that come with an "info" structure and have properties
and/or params also implement the WpPipewireObject interface. This
provides the API to query properties and get/set params. Essentially,
this is implemented by all classes except WpMetadata (pw_metadata
does not have info)
This interface is implemented on each object separately, using
a private "mixin", which is a set of vfunc implementations and helper
functions (and macros) to facilitate the implementation of this interface.
A notable difference to the old WpProxy is that now features can be
deactivated, so it is possible to enable something and later disable
it again.
This commit disables modules, tests, tools, etc, to avoid growing the
patch more, while ensuring that the project compiles.
object managers that are registered a bit early (such as the one in
wireplumber-cli) have no use if they are declared as installed before
any globals appear. After the initial registry startup, there should
be at least 1 global, the core (id=0), so even if this client has
no access to any object, the object manager should be able to
finish its installation successfully
When a pw_global is removed on the server (by pw_registry_destroy() or other
means), it triggers the proxy removed & the registry global_remove callbacks,
but it does not necessarily destroy the pw_proxy.
For client proxies, we were previously destroying them by unrefing the WpProxy
in wp_global_rm_flags(), since the global was not "owned" by the WpProxy.
For impl proxies, we were not doing anything, as we expected that it would
only be removed from the registry if the local WpProxy was destroyed first.
This is not always the case, though, as the server or another client may
request to destroy this proxy with pw_registry_destroy()
Now we always destroy the pw_proxy as soon as it is removed from the registry,
no matter if it was a client or an impl proxy. If it was an impl proxy,
the WpProxy will continue to live and it's up to the code that created it
to handle the "pw-proxy-destroyed" signal and do something meaningful.
If it was a client proxy, the global will still unref the WpProxy right after
destroying the pw_proxy and there is no change in behavior.
