GNOME Bugzilla – Bug 169405
[API] GST_TYPE_EVENT and gst_event_get_type unusable before gst_init()
Last modified: 2005-03-12 22:38:36 UTC
Both, the type macro and the type accessor for GstEvent are not usable till you call gst_init(). That's a problem for language bindings because it prevents you from creating GstEvent objects before gst_init() has been called. In general I think that at least the type accessor should return a valid type at all times.
But that goes for any type, right? You need to call g_type_init() (or whatever it's called) before doing anything anyway; gst_init() is just the same for us.
Yes, you need to call g_type_init() before any of the type stuff works at all. Our glib bindings do this automatically, and there's no way around it. But other than that, for normal gobject-based libraries, nothing else needs to be called before the type macros are usable (pango, gtk+, libgnome(ui), etc.). GStreamer already uses a hack to increase performance: some type macros point directly to the global type variable, instead of to the _get_type() function -- which means the type macros are not usable till the _get_type() function has been called at least once. But that can be easily worked around. Automatically calling gst_init() at startup is no real option, as it prevents the user from deciding when to initialize GStreamer -- which may sometimes be necessary. Currently, I work around this issue by delaying the registration and the setup of the GstEvent wrappers until after gst_init() has been called. That doesn't help other problems that mainly occur during installation, though: our documentation generation system relies on the introspection capabilities of the type system to create the hierarchy graphs, properties information, etc. for all the gobject-based libraries we wrap -- and it doesn't call any initialization function at the moment. Also, I don't see the reason for deviating from the usual behavior. Performance-wise it's just as fast as the hack used for other types.
I know it isn't faster, I'm trying to propose a practical solution.
I think a pragmatic solution would be the attached patch. It moves the type creation into gst_event_get_type() and calls that in gst_init(). AFAICT, this doesn't break neither API nor ABI nor the semantics of GstEvent. `make check` in testsuite/ passes as well (except for testsuite/threads/), and the regression tests for the Perl bindings are happy too.
Created attachment 38520 [details] [review] Moving type creation
That looks good to me. Any heavy objections?
ok, applied that, slightly different. thanks.