After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 575372 - [0.11] No way to unload the GModule of a plugin
[0.11] No way to unload the GModule of a plugin
Status: RESOLVED WONTFIX
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
git master
Other Linux
: Normal enhancement
: NONE
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2009-03-14 17:32 UTC by Edward Hervey
Modified: 2011-10-27 14:55 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Edward Hervey 2009-03-14 17:32:15 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).
Comment 1 Tim-Philipp Müller 2009-03-14 17:56:09 UTC
Isn't this going to be tricky with all the static GType registrations?
Comment 2 Edward Hervey 2009-03-14 18:20:52 UTC
damn, hadn't thought about that. Ok, will brainstorm a bit more about this then.
Comment 3 Jan Schmidt 2009-03-14 19:41:34 UTC
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.
Comment 4 Wim Taymans 2009-03-16 10:51:59 UTC
I we want to do this we need to rework eveything so that it uses the dynamic type registration in gobject.
Comment 5 Edward Hervey 2009-03-16 10:59:53 UTC
so we move this to a 0.11 feature ? Or can we do it without breaking API/ABI ? 
Comment 6 Sebastian Dröge (slomo) 2009-03-16 11:10:15 UTC
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.
Comment 7 David Schleef 2009-03-25 01:28:51 UTC
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.
Comment 8 Edward Hervey 2009-03-25 07:07:35 UTC
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.
Comment 9 Stefan Sauer (gstreamer, gtkdoc dev) 2009-03-30 09:07:38 UTC
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?
Comment 10 Jan Schmidt 2009-03-30 09:52:39 UTC
(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.
Comment 11 Stefan Sauer (gstreamer, gtkdoc dev) 2009-03-30 11:12:59 UTC
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)
Comment 12 Jan Schmidt 2009-03-30 12:29:12 UTC
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.
Comment 13 Tim-Philipp Müller 2011-10-27 14:55:23 UTC
Realistically, this is not going to happen, and needs lots of changes elsewhere and probably stuff to be fixed in GLib.