Re: GtkType defined in a gmodule?

[Tim Janik <timj gtk org>]

On 26 Jan 2001, Maciej Stachowiak wrote:

> 
> What's the right way to handle a GtkType that's defined in a loadable
> module that can get unloaded and reloaded multiple times? There's no
> way to remove an existing GtkType, so the module can't clean up on
> exit. However, from what I can see reusing the type by using
> gtk_type_from_name to get it is not really safe, since the GtkTypeNode
> contains pointers to things that could have changed addresses in the
> process of unloading and reloading the library. But there does not
> appear to be a way to change the already created GtkType either.
> 
> Is there no way to do this right? If so, the implications for shlib
> Bonobo components are very unfortunate.
> 
> If there is a way to do it I'd appreciate pointers.

the way types in dynamic modules work is this:

1) the type is initially introduced (usually upon loading the module
   the first time, or by you main application that knows what modules
   introduces what types), basically like this:
   new_type_id = g_type_register_dynamic (parent_type_id,
                                          "TypeName",
                                          new_type_plugin,
                                          type_flags);
   plugin is some code entity that adheares to the GTypePlugin interface
   defined in gtypeplugin.h, that is it needs to export following functions:
   typedef void  (*GTypePluginUse)                   (GTypePlugin     *plugin);
   typedef void  (*GTypePluginUnuse)                 (GTypePlugin     *plugin);
   typedef void  (*GTypePluginCompleteTypeInfo)      (GTypePlugin     *plugin,
                                                      GType            g_type,
                                                      GTypeInfo       *info,
                                                      GTypeValueTable *value_table);
2) the type's implementation is referenced, e.g. through
   g_type_class_ref (new_type_id); or through
   g_type_create_instance (new_type_id); (this is being called by g_obejct_new)
   or through one of the above done on a descendant type of new_type_id.
3) (2) causes they type system to load the type's implementation by doing:
   g_type_plugin_use (new_type_plugin);
   g_type_plugin_complete_type_info (new_type_plugin, ...);
4) at some point the type's implementation isn't required anymore, e.g. after
   g_type_class_unref (new_type_id); or
   g_type_free_instance (new_type_instance); (called from g_object_last_unref)
5) (4) causes the type system to throw away the information retrived from
   g_type_plugin_complete_type_info() and then it calls
   g_type_plugin_unuse (new_type_plugin);
6) things may repeat at (2)

so basically, you need to implement a GTypePlugin type that carries a
use_count, once use_count goes from 0->1, you need to load the implementation
to successfully handle the upcoming g_type_plugin_complete_type_info() call.
later, maybe after succeeding use/unuse calls, once use_count drops 1->0,
you can unload the implementation again, the type system makes sure to
call g_type_plugin_use() and g_type_plugin_complete_type_info() again
before reinitializing classes etc...

owen has written GTypeModule that basically does a bunch of the
required work already for you, GTypeModule is_a GObject and just
requires you to implement the actuall load/unload functions for
your modules. it'll handle multiple registered types per module
for etc and doe sthe use_count handling.

owen, i think it'd be a good idea to make load/unload signals
on GTypeModule, so people can use it to handle their dynamic
types without needing to derive from it.

> 
>  - MAciej
> 

---
ciaoTJ