Re: Potential need for librsvg API breakage
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 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Potential need for librsvg API breakage
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 -- 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 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Potential need for librsvg API breakage
On Wed, 1 Nov 2006, 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. 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. 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. 3) Whatever you all come up with 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 ;) Thanks for your help and understanding, Dom --- ciaoTJ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
