wireplumber/lib/wp/factory.c

178 lines
4.4 KiB
C
Raw Normal View History

/* WirePlumber
*
* Copyright © 2019 Collabora Ltd.
* @author George Kiagiadakis <george.kiagiadakis@collabora.com>
*
2019-05-31 12:13:01 +03:00
* SPDX-License-Identifier: MIT
*/
2020-02-17 15:39:19 +02:00
/**
* SECTION: WpFactory
*
* The #WpFactory class allows associating a function that is able to construct
* objects with a well-known name that is registered on the #WpCore
*/
#include "factory.h"
#include "private.h"
struct _WpFactory
{
GObject parent;
GWeakRef core;
gchar *name;
GQuark name_quark;
WpFactoryFunc create_object;
};
G_DEFINE_TYPE (WpFactory, wp_factory, G_TYPE_OBJECT)
static void
wp_factory_init (WpFactory * self)
{
}
static void
wp_factory_finalize (GObject * obj)
{
WpFactory * self = WP_FACTORY (obj);
2019-05-26 12:36:20 +03:00
g_debug ("WpFactory:%p destroying factory: %s", self, self->name);
g_weak_ref_clear (&self->core);
g_free (self->name);
G_OBJECT_CLASS (wp_factory_parent_class)->finalize (obj);
}
static void
wp_factory_class_init (WpFactoryClass * klass)
{
GObjectClass *object_class = (GObjectClass *) klass;
object_class->finalize = wp_factory_finalize;
}
2019-07-10 11:15:33 -04:00
/**
* wp_factory_new:
* @core: the core
* @name: the name of the factory
* @func: the create object callback
*
lib: introduce WpObjectManager * rework how global objects are stored in the core * rework how users get notified about global objects and proxies of remote global objects The purpose of this change is to have a class that can manage objects that are registered in the core or signalled through the registry. This object can declare interest on certain types of global objects and only keep & signal those objects that it is interested in. Additionally, it can prepare proxy features and asynchronously deliver an 'objects-changed' signal, which is basically telling us that the list of objects has changed. This is useful to simplify port proxies management in WpAudioStream. Now the stream object can declare that it is interested in ports that have "node.id" == X and the object manager will only maintain a list of those. Additionally, it will emit the 'objects-changed' signal when the list of ports is complete, so there is no reason to do complex operations and core syncs in the WpAudioStream class in order to figure out when the list of ports is ready. As a side effect, this also reduces resource management. Now we don't construct a WpProxy for every global that pipewire reports; we only construct proxies when there is interest in them! Another interesting side effect is that we can now register an object manager at any point in time and get immediately notified about remote globals that already exist. i.e. when you register an object manager that is interested in nodes, it will be immediately notified about all the existing nodes in the graph. This is useful to avoid race conditions between connecting the signal and objects beting created in pipewire
2019-11-13 15:44:23 +02:00
* Returns: (transfer none): the newly created factory. No reference
* is passed to the caller, since the reference is held by the core.
* The caller is free to ignore the return value
2019-07-10 11:15:33 -04:00
*/
WpFactory *
2019-07-10 11:15:33 -04:00
wp_factory_new (WpCore * core, const gchar * name, WpFactoryFunc func)
{
WpFactory *f = NULL;
g_return_val_if_fail (func, NULL);
g_return_val_if_fail (name != NULL && *name != '\0', NULL);
f = g_object_new (WP_TYPE_FACTORY, NULL);
g_weak_ref_init (&f->core, core);
f->name = g_strdup (name);
f->name_quark = g_quark_from_string (f->name);
f->create_object = func;
2019-05-26 12:36:20 +03:00
g_info ("WpFactory:%p new factory: %s", f, name);
wp_registry_register_object (wp_core_get_registry (core), f);
return f;
}
2020-02-17 15:39:19 +02:00
/**
* wp_factory_get_name:
* @self: the factory
*
* Returns: the factory name
*/
const gchar *
wp_factory_get_name (WpFactory * self)
{
return self->name;
}
/**
* wp_factory_get_core:
* @self: the factory
*
* Returns: (transfer full): the core on which this factory is registered
*/
WpCore *
wp_factory_get_core (WpFactory * self)
{
return g_weak_ref_get (&self->core);
}
2020-02-17 15:39:19 +02:00
/**
* wp_factory_create_object:
* @self: the factory
* @type: the object type to construct
* @properties: a dictionary ("a{sv}") variant with additional properties
* @ready: (scope async): a callback to call when the object is constructed
* and ready
* @user_data: (closure): data to pass to @ready
*
* Calls the #WpFactoryFunc of this factory
*/
2019-06-20 14:39:20 -04:00
void
wp_factory_create_object (WpFactory * self, GType type,
2019-06-20 14:39:20 -04:00
GVariant * properties, GAsyncReadyCallback ready, gpointer user_data)
{
g_debug ("WpFactory:%p (%s) create object of type %s", self, self->name,
2019-06-20 14:39:20 -04:00
g_type_name (type));
self->create_object (self, type, properties, ready, user_data);
}
static gboolean
lib: introduce WpObjectManager * rework how global objects are stored in the core * rework how users get notified about global objects and proxies of remote global objects The purpose of this change is to have a class that can manage objects that are registered in the core or signalled through the registry. This object can declare interest on certain types of global objects and only keep & signal those objects that it is interested in. Additionally, it can prepare proxy features and asynchronously deliver an 'objects-changed' signal, which is basically telling us that the list of objects has changed. This is useful to simplify port proxies management in WpAudioStream. Now the stream object can declare that it is interested in ports that have "node.id" == X and the object manager will only maintain a list of those. Additionally, it will emit the 'objects-changed' signal when the list of ports is complete, so there is no reason to do complex operations and core syncs in the WpAudioStream class in order to figure out when the list of ports is ready. As a side effect, this also reduces resource management. Now we don't construct a WpProxy for every global that pipewire reports; we only construct proxies when there is interest in them! Another interesting side effect is that we can now register an object manager at any point in time and get immediately notified about remote globals that already exist. i.e. when you register an object manager that is interested in nodes, it will be immediately notified about all the existing nodes in the graph. This is useful to avoid race conditions between connecting the signal and objects beting created in pipewire
2019-11-13 15:44:23 +02:00
find_factory_func (gpointer factory, gpointer name_quark)
{
lib: introduce WpObjectManager * rework how global objects are stored in the core * rework how users get notified about global objects and proxies of remote global objects The purpose of this change is to have a class that can manage objects that are registered in the core or signalled through the registry. This object can declare interest on certain types of global objects and only keep & signal those objects that it is interested in. Additionally, it can prepare proxy features and asynchronously deliver an 'objects-changed' signal, which is basically telling us that the list of objects has changed. This is useful to simplify port proxies management in WpAudioStream. Now the stream object can declare that it is interested in ports that have "node.id" == X and the object manager will only maintain a list of those. Additionally, it will emit the 'objects-changed' signal when the list of ports is complete, so there is no reason to do complex operations and core syncs in the WpAudioStream class in order to figure out when the list of ports is ready. As a side effect, this also reduces resource management. Now we don't construct a WpProxy for every global that pipewire reports; we only construct proxies when there is interest in them! Another interesting side effect is that we can now register an object manager at any point in time and get immediately notified about remote globals that already exist. i.e. when you register an object manager that is interested in nodes, it will be immediately notified about all the existing nodes in the graph. This is useful to avoid race conditions between connecting the signal and objects beting created in pipewire
2019-11-13 15:44:23 +02:00
return WP_IS_FACTORY (factory) &&
WP_FACTORY (factory)->name_quark == GPOINTER_TO_UINT (name_quark);
}
2019-07-10 11:15:33 -04:00
/**
* wp_factory_find:
* @core: the core
* @name: the lookup name
*
lib: introduce WpObjectManager * rework how global objects are stored in the core * rework how users get notified about global objects and proxies of remote global objects The purpose of this change is to have a class that can manage objects that are registered in the core or signalled through the registry. This object can declare interest on certain types of global objects and only keep & signal those objects that it is interested in. Additionally, it can prepare proxy features and asynchronously deliver an 'objects-changed' signal, which is basically telling us that the list of objects has changed. This is useful to simplify port proxies management in WpAudioStream. Now the stream object can declare that it is interested in ports that have "node.id" == X and the object manager will only maintain a list of those. Additionally, it will emit the 'objects-changed' signal when the list of ports is complete, so there is no reason to do complex operations and core syncs in the WpAudioStream class in order to figure out when the list of ports is ready. As a side effect, this also reduces resource management. Now we don't construct a WpProxy for every global that pipewire reports; we only construct proxies when there is interest in them! Another interesting side effect is that we can now register an object manager at any point in time and get immediately notified about remote globals that already exist. i.e. when you register an object manager that is interested in nodes, it will be immediately notified about all the existing nodes in the graph. This is useful to avoid race conditions between connecting the signal and objects beting created in pipewire
2019-11-13 15:44:23 +02:00
* Returns: (transfer full): the factory matching the lookup name
2019-07-10 11:15:33 -04:00
*/
WpFactory *
wp_factory_find (WpCore * core, const gchar * name)
{
lib: introduce WpObjectManager * rework how global objects are stored in the core * rework how users get notified about global objects and proxies of remote global objects The purpose of this change is to have a class that can manage objects that are registered in the core or signalled through the registry. This object can declare interest on certain types of global objects and only keep & signal those objects that it is interested in. Additionally, it can prepare proxy features and asynchronously deliver an 'objects-changed' signal, which is basically telling us that the list of objects has changed. This is useful to simplify port proxies management in WpAudioStream. Now the stream object can declare that it is interested in ports that have "node.id" == X and the object manager will only maintain a list of those. Additionally, it will emit the 'objects-changed' signal when the list of ports is complete, so there is no reason to do complex operations and core syncs in the WpAudioStream class in order to figure out when the list of ports is ready. As a side effect, this also reduces resource management. Now we don't construct a WpProxy for every global that pipewire reports; we only construct proxies when there is interest in them! Another interesting side effect is that we can now register an object manager at any point in time and get immediately notified about remote globals that already exist. i.e. when you register an object manager that is interested in nodes, it will be immediately notified about all the existing nodes in the graph. This is useful to avoid race conditions between connecting the signal and objects beting created in pipewire
2019-11-13 15:44:23 +02:00
GObject *f;
GQuark q = g_quark_from_string (name);
f = wp_registry_find_object (wp_core_get_registry (core),
(GEqualFunc) find_factory_func, GUINT_TO_POINTER (q));
lib: introduce WpObjectManager * rework how global objects are stored in the core * rework how users get notified about global objects and proxies of remote global objects The purpose of this change is to have a class that can manage objects that are registered in the core or signalled through the registry. This object can declare interest on certain types of global objects and only keep & signal those objects that it is interested in. Additionally, it can prepare proxy features and asynchronously deliver an 'objects-changed' signal, which is basically telling us that the list of objects has changed. This is useful to simplify port proxies management in WpAudioStream. Now the stream object can declare that it is interested in ports that have "node.id" == X and the object manager will only maintain a list of those. Additionally, it will emit the 'objects-changed' signal when the list of ports is complete, so there is no reason to do complex operations and core syncs in the WpAudioStream class in order to figure out when the list of ports is ready. As a side effect, this also reduces resource management. Now we don't construct a WpProxy for every global that pipewire reports; we only construct proxies when there is interest in them! Another interesting side effect is that we can now register an object manager at any point in time and get immediately notified about remote globals that already exist. i.e. when you register an object manager that is interested in nodes, it will be immediately notified about all the existing nodes in the graph. This is useful to avoid race conditions between connecting the signal and objects beting created in pipewire
2019-11-13 15:44:23 +02:00
return f ? WP_FACTORY (f) : NULL;
}
2020-02-17 15:39:19 +02:00
/**
* wp_factory_make:
* @core: the #WpCore
* @name: the name of the factory to be used for constructing the object
* @type: the object type to construct
* @properties: a dictionary ("a{sv}") variant with additional properties
* @ready: (scope async): a callback to call when the object is constructed
* and ready
* @user_data: (closure): data to pass to @ready
*
* Finds the factory associated with the given @name from the @core and
* calls its #WpFactoryFunc with the rest of the arguments to create
* an object. The new object is notified through the @ready callback.
*/
2019-06-20 14:39:20 -04:00
void
wp_factory_make (WpCore * core, const gchar * name, GType type,
2019-06-20 14:39:20 -04:00
GVariant * properties, GAsyncReadyCallback ready, gpointer user_data)
{
lib: introduce WpObjectManager * rework how global objects are stored in the core * rework how users get notified about global objects and proxies of remote global objects The purpose of this change is to have a class that can manage objects that are registered in the core or signalled through the registry. This object can declare interest on certain types of global objects and only keep & signal those objects that it is interested in. Additionally, it can prepare proxy features and asynchronously deliver an 'objects-changed' signal, which is basically telling us that the list of objects has changed. This is useful to simplify port proxies management in WpAudioStream. Now the stream object can declare that it is interested in ports that have "node.id" == X and the object manager will only maintain a list of those. Additionally, it will emit the 'objects-changed' signal when the list of ports is complete, so there is no reason to do complex operations and core syncs in the WpAudioStream class in order to figure out when the list of ports is ready. As a side effect, this also reduces resource management. Now we don't construct a WpProxy for every global that pipewire reports; we only construct proxies when there is interest in them! Another interesting side effect is that we can now register an object manager at any point in time and get immediately notified about remote globals that already exist. i.e. when you register an object manager that is interested in nodes, it will be immediately notified about all the existing nodes in the graph. This is useful to avoid race conditions between connecting the signal and objects beting created in pipewire
2019-11-13 15:44:23 +02:00
g_autoptr (WpFactory) f = wp_factory_find (core, name);
2019-06-20 14:39:20 -04:00
if (!f) return;
wp_factory_create_object (f, type, properties, ready, user_data);
2019-06-20 14:39:20 -04:00
}