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 338339 - [patch] registry cache is always written
[patch] registry cache is always written
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
git master
Other Linux
: Normal normal
: 0.10.6
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2006-04-13 11:49 UTC by Stefan Sauer (gstreamer, gtkdoc dev)
Modified: 2006-05-12 09:41 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
only write registry cache after the registry has changed (4.65 KB, patch)
2006-04-13 14:23 UTC, Stefan Sauer (gstreamer, gtkdoc dev)
committed Details | Review

Description Stefan Sauer (gstreamer, gtkdoc dev) 2006-04-13 11:49:08 UTC
when looking at gst.c::init_post() nconditionally calls gst_registry_xml_write_cache (default_registry, registry_file);

Also one can see that the registry file has been touched after each gst-inspect call.

Shouldn't gst_registry_scan_path() get a gboolean return to indicate if there has been a change? If so, I'll provide a patch.

The current behaviour causes a substantial delay of application start on weak devices.
Comment 1 Stefan Sauer (gstreamer, gtkdoc dev) 2006-04-13 14:23:03 UTC
Created attachment 63387 [details] [review]
only write registry cache after the registry has changed

patch done against gstreamer-0.10.4 :( - hope i applies
Comment 2 Wim Taymans 2006-04-13 18:16:36 UTC
it is unfortunatily an API change. It adds a return value to a function that did not have one before. Surely applications that compiled against the old function compile against the new one as well but does it not break ABI?
Comment 3 Tim-Philipp Müller 2006-04-13 18:31:18 UTC
Apparently it does not break ABI, it's been done a few times in Gtk+ as far as I know.

Also, Owen Taylor dixit:
 http://mail.gnome.org/archives/language-bindings/2004-March/msg00001.html
Comment 4 Jan Schmidt 2006-04-13 19:45:53 UTC
It'll break anything that's being compiled with -Werror and warning about ignored return values, but that's the only problem I can see.

If that's a worry we could add gboolean gst_registry_scan_path_changes() and just call that from gst_registry_scan_path()
Comment 5 Michael Smith 2006-04-13 20:14:32 UTC
Fortunately, gcc has no warning option that will cause it to warn about unused return values except on functions with a special attribute. So, unless other compilers have that (and on such a compiler, we might reasonably expect other warnings, so -Werror or equivalent would be inappropriate anyway), it's not a problem at all.

As noted in the thread Tim pointed to, the only problem would be if someone is using function pointers to gst_registry_scan_path(). I think this is vanishingly unlikely, and would be only a trivial API change anyway (NOT an ABI change).

Comment 6 Jan Schmidt 2006-04-14 04:12:00 UTC
Then there ain't nuthin' to it but to do it
Comment 7 W. Michael Petullo 2006-04-20 22:16:17 UTC
This issue becomes a problem when $HOME is not on a fast drive.  For example, my $HOME is mounted using NFS and this registry generation takes quite a while.