GNOME Bugzilla – Bug 575372
[0.11] No way to unload the GModule of a plugin
Last modified: 2011-10-27 14:55:23 UTC
On certain systems (yes, Android!) there's a limit to the number of simultaneously loaded shared libraries for a given process. When scanning the registry initially, the GModule corresponding to a GstPlugin is never unloaded (after having collected the required information of course). We should have a method to 'unload' a plugin. Thereby still keeping the GstPlugin alive with all its information except for the GModule (which can be reloaded later on if needed).
Isn't this going to be tricky with all the static GType registrations?
damn, hadn't thought about that. Ok, will brainstorm a bit more about this then.
Right - the GType registrations are the reason we don't allow the unloading at the moment. With my registry-rewrite branch (in by personal git repo on fdo), the scanning and plugin loading is done in a separate spawned process. It'd be possible to make that child process close and respawn every X plugins, which would limit the number of simultaneously loaded libs, at the cost of increasing the plugin scanning time. I don't know how you'd measure when you were approaching the limit so you could respawn the child though.
I we want to do this we need to rework eveything so that it uses the dynamic type registration in gobject.
so we move this to a 0.11 feature ? Or can we do it without breaking API/ABI ?
But then the dynamic types of GObject have some other problems... if a plugin is unloaded, then the plugin file is changed in an ABI incompatible way, and then the plugin is loaded again things will break in interesting ways. At least this was the case some years ago.
It definitely cannot be done without breaking ABI. It's unclear whether it can be fully supported without changes in GLib that would break GLib's ABI and/or require a full replacement of the dynamic type system. I attempted to do this back in the 0.6/0.7/0.8 days, and eventually gave up because glib's functionality in this area was immature. I haven't heard of any related development in glib, so I assume the situation is the same.
Marking it as a 0.11 feature request. Hopefully we'll have enough time to figure out what remains to be done in GLib for this to work.
What I wonder is that if we just updated the registry in the forked process, shouldn't it be fine to unload the plugins, because we don't use them afterwards anyway?
(In reply to comment #9) > What I wonder is that if we just updated the registry in the forked process, > shouldn't it be fine to unload the plugins, because we don't use them > afterwards anyway? I don't know what you mean - if they're only loaded in the forked process, they'll go away when that exits.
Jan, according to Edwards initial comment its a problem on Android, as they don't allow to have unlimmited libraries dlopen'ed. We could close the modules after introspecting them. That is in gst_registry_scan_path_level() if we called gst_plugin_load_file(), we could do a g_module_close(plugin->module)
Oh right, I see what you're saying. It's certainly worth a try, although it might lead to problems with the GType's still existing in GLib/GObject's internal data structures. I don't know if there's any way that it might rely on no-longer-mapped data or code internally, even if we don't touch it ourselves.
Realistically, this is not going to happen, and needs lots of changes elsewhere and probably stuff to be fixed in GLib.