[gstreamer-bugs] [Bug 391278] gst programmes don't call g_thread_init early enough
bugzilla-daemon at bugzilla.gnome.org
Tue Jan 2 03:23:18 PST 2007
Do not reply to this via email (we are currently unable to handle email
responses and they get discarded). You can add comments to this bug at
GStreamer | don't know | Ver: HEAD CVS
------- Comment #2 from Tim-Philipp Müller 2007-01-02 11:21 UTC -------
Created an attachment (id=79172)
Init GLib threads in constructor, and warn if that's not possible and threads
haven't been initialised elsewhere
Not sure what to do about this. Two possibilities come to mind:
1) Change our init semantics. This probably means most applications
initialising GStreamer via GOption need to be changed/fixed.
2) Try to initialise the threading system in a constructor and issue
a warning in cases where that's not possible (ie. where the compiler
does not support it or we don't have special code for that compiler)
and where the threading system hasn't been initialised by the time
the application calls gst_init_get_option_group(). This would only
affect applications that link against a GStreamer that hasn't been
compiled with GCC or Forte and that use GOption for initing and
haven't inited the threads system otherwise yet. And even for those
cases there's not really a functional regression, we just init the
thread system as early as possible, issue a warning and keep our
our fingers crossed.
Can anyone think of a better option?
Attached patch implements option 2).
Configure bugmail: http://bugzilla.gnome.org/userprefs.cgi?tab=email
More information about the Gstreamer-bugs