[gst-devel] [gst-cvs] tpm gstreamer: gstreamer/ gstreamer/gst/

David Schleef ds at schleef.org
Fri Nov 9 22:30:25 CET 2007


On Wed, Nov 07, 2007 at 07:53:44AM +0100, Stefan Kost wrote:
> Hi,
> 
> Quoting Tim Müller <t.i.m at zen.co.uk>:
> 
> > On Tue, 2007-11-06 at 21:46 +0200, Stefan Kost wrote:
> >
> >> > * gst/gstdebugutils.c: (debug_dump_element),
> >> >   (_gst_debug_bin_to_dot_file), (_gst_debug_bin_to_dot_file_with_ts):
> >> >   Don't use VLAs which is a C99ism and throws off MSVC (#493983).
> >>
> >> Wouldn't that be a use case of g_alloca ?
> >
> > g_alloca() would have been a possibility too, yes.  But since the patch
> > provided used g_malloc() and I personally have a strong dislike against
> > g_alloca() and we don't use it anywhere else in the core, I did not
> > change it.
> >
> We were using it a.g. in alsa. And we should us it more. GStreamer  
> causes quite a lot of memory fragmentation. I can rewrite this to do  
> better in the next cycle.

GStreamer, as well as a sizeable percentage of other projects,
have a long-standing rule against not using alloca(), ever.  Few
people know the detailed rules of when it's safe to use, leading
to maintenence problems.  One could write down some simpler rules,
but all those cases are better served by local variables or using
malloc.

Also, memory fragmentation is a property of the libc allocator, not
GStreamer.  If GStreamer's allocator usage patterns cause problems
for the allocator, that's a bug in libc, not in GStreamer.  Changing
a few mallocs to allocas will not really make a dent in the usage
patterns, anyway.

See also: http://c-faq.com/malloc/alloca.html



dave...





More information about the gstreamer-devel mailing list