As tim said on irc,

"gconf does the parsing only when going from NULL => READY I believe, so it probably doesn't run into this problem"

And tim is right, you won't see the problem :)

You have to know that the most difficult case is when you are parsing the same string recursively:

$ gst-launch element adescription="anotherelement !..." ...

And for the moment, gst-launch (the parsing) crash when you do that.
 
Cheers,

On 7/30/06, Zaheer Merali <zaheermerali@gmail.com> wrote:
Hi

Having spoken in the channel, this re-entrancy issue could potentially
be a problem for the gconf plugins, gconfaudiosrc, gconfaudiosink etc.

It would howver be nice to be shown valgrind output of a gst-launch
line with gconfaudiosink in for example.

Zaheer

On 7/30/06, Stefan Kost <ensonic@hora-obscura.de> wrote:
> hi,
>
> This weekend Marc-Andre has provided a patch in
> http://bugzilla.gnome.org/show_bug.cgi?id=349180
> to make the gst_parse_launch reentrant.
>
> Unfortunately Fedora core 4/5 ships an ancient version of flex which
> can't do the reentrancy. As this is only a build dependency, what do you
> think about bumping the requirement. Just for your information flext
> 2.5.4.a ist from 1997. The release from 2003 would do it. So we would
> not require anything bleeding edge.
>
> Stefan & Marc-Andre

--
Marc-André Lureau, GSmartMix