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 348179 - gst_parse_lauch is not reentrant
gst_parse_lauch is not reentrant
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
git master
Other Linux
: Normal enhancement
: 0.10.10
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2006-07-20 19:59 UTC by Stefan Sauer (gstreamer, gtkdoc dev)
Modified: 2006-07-21 18:56 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Stefan Sauer (gstreamer, gtkdoc dev) 2006-07-20 19:59:45 UTC 
previouse version would just hang when gst_parse_launch get called again. An example is a bin element that uses gst_parse_launch to create its contents from a property. Using such an element together with gst-launch hangs.
Comment 1 Wim Taymans 2006-07-21 17:09:10 UTC 
Made the calls to _parse () fail if called recursively instead of locking. Concurrent threads serialize their _parse() code fine.

        * gst/gstparse.c: (gst_parse_launch):
        Protect recursive calls to _parse with a recursive mutex
        and busy flag.
Comment 2 Wim Taymans 2006-07-21 17:10:13 UTC 
not closing, it might be possible to add configure checks so we only use newer threadsafe versions of flex. Marking as enhancement.
Comment 3 Stefan Sauer (gstreamer, gtkdoc dev) 2006-07-21 18:56:04 UTC 
fixed in CVS

2006-07-21  Stefan Kost  <ensonic@users.sf.net>

	* configure.ac:
	* gst/gstparse.c: (gst_parse_launch):
          Check for flex version and omit mutex if we have a MT save flex
          Also remove reentrance checks if flex is MT save (#348179)