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 342777 - rebuilding the registry leaves all plugins in memory
rebuilding the registry leaves all plugins in memory
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
git master
Other Linux
: Normal normal
: 0.10.7
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2006-05-24 09:09 UTC by Thomas Vander Stichele
Modified: 2006-05-28 09:31 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
fork before rebuilding registry (6.21 KB, patch)
2006-05-24 09:09 UTC, Thomas Vander Stichele
committed Details | Review

Description Thomas Vander Stichele 2006-05-24 09:09:23 UTC
When the registry cache is stale, gst rebuilds it completely.  In the process of doing so, it loads all .so files that it finds, and they cannot be unloaded.  If this is a long-running process (like, say, mixer applet or gnome-settings-daemon), this is a problem.

We already discussed possible solutions, like forking to rebuild the registry.

The attached patch is a first attempt at doing so.  To test it, remove your registry and run gst-launch-0.10 fakesrc ! fakesink

Attaching with gdb should show that none of the plugins not needed are loaded.  Without the patch, all of them are loaded.

Drawbacks:
- windows doesn't have fork.  we could ifdef out that part on windows, and still have the benefit on unix.  Or maybe there are alternatives.
- right now the code always forks.  This is because rebuilding the registry is intertwined with adding paths to the registry; ie, the loading happens automatically behind our back.  It would be great if we could make the registry not do so, and instead just "prime" it with paths then query it somehow if it will need rebuilding.
- We still have a race condition in that multiple processes could be trying to rebuild the registry.  It's fairly minimal at the moment, but it'd be nice if we could eliminate it.  Not sure if file locking is the way to go - anyone know if there are guaranteed ways of cleaning up ?
Comment 1 Thomas Vander Stichele 2006-05-24 09:09:51 UTC
Created attachment 66113 [details] [review]
fork before rebuilding registry
Comment 2 Thomas Vander Stichele 2006-05-24 09:18:10 UTC
From the unreliable measurement tool that is top:

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND

without patch

 4500 thomas    15   0 71896  14m 9712 S 99.9  1.4   0:48.25 lt-gst-launch-0

with patch

 5934 thomas    15   0 37908 2936 2120 S 99.4  0.3   0:08.92 lt-gst-launch-0
Comment 3 Jan Schmidt 2006-05-24 09:39:52 UTC
This generally looks ok to me, properly stubbed out so it works on Windows.

I was wondering whether it would be possible to fork the task off to scan in the background, and then block and wait for the child only when the first user tries to access the registry. This depends on the entry points to the registry being sufficiently well defined, and I haven't had time to check that.
Comment 4 Thomas Vander Stichele 2006-05-28 09:09:00 UTC
Yeah, that would be nice.  However, it would also make the code messier (I have three ifdef's now, it's ugly but still readable) and it would probably get a little worse if we want to move tidying up to the registry class.

Do you want to open a separate bug for that ?