On Mon, 18 Jun 2007, Alberto Mardegan wrote:
> Still, the point applies to other libraries, such as DBus-glib (it uses
> g_boxed_type_register_static()) or any library which registers any static
> GType: the application cannot know what libraries the plugins are linked to,
> and in most cases even if it new, it wouldn't want to keep the libraries
> loaded when they are unneeded.
any library that uses g_type_register_static() (or g_boxed_type_register_static)
cannot be unloaded. if you intend to make it unloadable, you need to convert it
to use g_type_register_dynamic() instead, *and* you have to audit the rest of
the
code to convert/avoid similar related APIs. e.g. you also couldn't use atexit(),
or g_quark_from_static_string(), be carefull with static pointers in
g_type_{set|get}_qdata, etc.
> I'm not convinced that the solution is to convert all libraries using static
> types need to use dynamic types -- I'd rather have some workaround in glib.
if you look for a variant of g_type_register_static() that
"works around" it's static implementation assumptions,
glib provides g_type_register_dynamic() for you.
> What about allowing g_type_register_static() to overwrite the previous
> existing type when asked to re-register an already known type, instead of
> failing?
glib provides two kind of type registration APIs:
a) type registration API to use for types implemented in code that gets
*never* unloaded, i.e. pointer referenes remain valid throughout all of a
programs lifetime. various API and implementation details rely on that:
g_type_register_static, g_type_add_interface_static,
g_boxed_type_register_static, ...
b) type registration API to use for types implemented in code that is
possibly unloaded and possibly changes behavior, and where pointer
references can become invalid at a specific known point in time.
various measures are taken to allow for this:
g_type_register_dynamic, g_type_add_interface_dynamic
if your code should be unloadable, you must use the *_dynamic interfaces
from (b), and you must not use any of the *_static interfaces from (a).
for code and pointers guaranteed to remain valid/static throughout a programs
runtime, you can use the API from (b) or the simpler to use and for this
case more efficient API from (a).
> It doesn't sound a clean solution at all, but...
it is not a solution at all. the neccessary logic needed for
dynamic type implementations is mapped onto the *_dynamic
type API by glib.
> Ciao,
> Alberto
---
ciaoTJ
_______________________________________________
gtk-devel-list mailing list
[email protected]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
