Re: Potential need for librsvg API breakage

[Rodney Dawes <dobey novell com>]

Ah, so that's why all the plug-ins in encompass are going whacky now.
I spent a damn long time trying to debug why the hell it was giving me
"already registered" errors. I even wrote a simplified module loading
test case, but that of course had no problems. Of course, encompass is
still having the problem. My current suspicion is that the use of bonobo
in encompass is causing it to break for some reason. It seemed to work
OK when I short-circuited all the bonobo server startup bits.

And I agree. This API breakage sucks.

-- dobey


On Wed, 2006-11-01 at 15:02 -0500, Dominic Lachowicz wrote:
> Hi,
> 
> So I'm currently faced with a dilemma that's hitting a lot of users,
> causing their applications to crash and otherwise behave badly. I'd
> appreciate if people might offer any insight they had on the issue.
> 
> In the 2.16.x series, librsvg's fundamental "type", the RsvgHandle,
> became a subclass of GObject, and is registered via
> g_type_register_static(). AFAIK, this relationship isn't exposed in
> any way that the public ABI is concerned (i.e. RsvgHandle is just a
> anonymous typedef in the header file).
> 
> The problem is that librsvg is a library that gets used by a lot of
> plugins - I can think of at least 3 places: AbiWord's image loader,
> GdkPixbuf's "loader" architecture, and GTK+'s theme engine. Some of
> these (GTK+'s theme engine bits come to mind) make heavy use of what
> GObject calls "dynamic types" that get loaded/unloaded as necessary,
> and the GModule that ultimately called
> g_type_register_static(RSVG_TYPE_HANDLE, ...) may get unloaded. Since
> there is no way to signal that types need to be unregistered, this
> causes subsequent registration of the RsvgHandle type to fail, and
> lots of code to go belly-up. This is bad.
> 
> Now, I don't intend to pass judgment on the type registration system.
> I just want to come up with the best way to fix the problem I'm
> encountering. I can think of a few solutions, but I welcome other
> ideas and suggestions for implementing my proposals.
> 
> 1) Make helper-processes that do the heavy lifting. Have the plugins
> call those processes via a wire protocol (see also: The Gimp). The
> helper-process calls type registration. Problem goes away.
> Pros: No API breakage
> Cons: A decent amount of work. Performance penalties in at least 2
> places (pixbuf loading, theme engine) where performance actually
> matters.
> 
> 2) Break API. Involves changing documentation, removing type
> registration, etc. Probably need to tweak libtool bits to suggest
> interface breakage.
> Pros: No performance hit
> Cons: The obvious. Plus, Rsvg makes use of other GObject-based
> libraries (libgsf, gnome-vfs) that may still in-turn exhibit problems.
> 
> 3) Whatever you all come up with
> 
> Thanks for your help and understanding,
> Dom