Re: Using static types from a GTypeModule

[Tim Janik <timj gtk org>]

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