Re: Potential need for librsvg API breakage

["Dominic Lachowicz" <domlachowicz gmail com>]

Hi Tim,

> this is already broken and has to be fixed.
> if you want to be able to unload a type implementaiton, you MUST
> use g_type_register_dynamic.
> using g_type_register_static and unloading its implementaiton is as
> good as dlopen(); atexit(dlsym()); dlclose();
> the alternative is of course to make the module effectively unloadable
> by means of g_module_make_resident or dlopen(self) once loaded.

It's not something that I'm in control of, which is the problem. The
problem is that a plugin (be it GdkPixbuf or some 3rd-party plugin
that I'm not aware of) will call rsvg_handle_new() directly or
indirectly, which looks innocuous enough. But behind that, there is a
call to g_type_register_static(), which becomes problematic.

Now, this is a caveat to be aware of when using GObject that should be
advertised in big bold neon blinking text, and I found this out the
hard way. Mea culpa.

However, I don't see how I can keep RsvgHandle as a GObject subclass
while retaining the ability to use librsvg in various plugins that
might get unloaded. Thus my question about breaking API to revert the
use of GObject, and asking if there is a better alternative, because
I'm not seeing one.

> i'm not sure what exactly your problem is here.
> if it's just the combo of g_type_register_static + unloading,
> simply prevent unloading or use g_type_register_dynamic.
> if it's something else, i didn't manage to grasp it from your email ;)

I don't control the loading/unloading of these modules, nor do I wish
to. I also don't necessarily have a GTypeModule* to pass to a GType
registration function, nor do I wish to muddy librsvg's public API to
accommodate what is (in my mind) a hackish workaround.

Best,
Dom
--
"I believe in making the world safe for our children, but not our
children's children, because I don't think children should be having
sex." -Jack Handy