[gstreamer-bugs] [Bug 391278] gst programmes don't call g_thread_init early enough

[GStreamer (bugzilla.gnome.org)]

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
http://bugzilla.gnome.org/show_bug.cgi?id=391278

  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)
 --> (http://bugzilla.gnome.org/attachment.cgi?id=79172&action=view)
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