GNOME Bugzilla – Bug 342777
rebuilding the registry leaves all plugins in memory
Last modified: 2006-05-28 09:31:37 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 ?
Created attachment 66113 [details] [review] fork before rebuilding registry
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
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.
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 ?