[Scummvm-devel] CVS: "added extra flag to mixer so we don't use free() on new'd pointers"

Max Horn max at quendi.de
Sat Oct 25 05:28:01 CEST 2003

Am Samstag, 25.10.03 um 13:38 Uhr schrieb Marcus Comstedt:

> Joost Peters <j at 7fc1.org> writes:
>> It's not simply a matter of changing the new to malloc() as the same
>> function that allocates the memory passed to the mixer is also used 
>> all over
>> the place in Queen (and they DELETE memory returned from it), so I can
>> either change all those references to free(), or add this to the 
>> mixer. Take
>> a pick.
> Maybe the real question is why the mixer frees something it didn't
> allocate in the first place.

First off, that's because the mixer has to work async, and hence the 
caller can't determine when it can free the temporary buffer it may 
have used for the audio data. Hence we leave it to the mixer to free 
that buffer.

The alternative is that the mixer, when you give it data to play, 
allocates a new buffer and copies all the data. Note that in virtually 
all cases, the original buffer is not used anymore by the caller, hence 
it gets deleted there. So you end up with a typical data flow like this:
1) allocate temp sound buffer
2) fill sound buffer
3) pass buffer to mixer
4) mixer allocates yet another buffer and memcpy's the content
5) temp sound buffer is free'd
6) when the mixer is done playing the sound, that buffer is free'd, too

That's a lot of memory & CPU time overhead. Granted, on most machine we 
don't care about spending another MB or so for memory.

>  That's a layering violation, and should never happen (regardless of 
> flags) IMNSHO.

IMHO this is most of the time true, but certainly not always. Transfer 
of ownership is something one usually avoids, because it makes it 
harder to follow the life time of an object. However, that doesn't mean 
one should do strange things and bend over backwards just to avoid it 
at all times. Sometimes transfer of  ownership of an object is in fact 
the most logical, efficient, and easiest alternative.



More information about the Scummvm-devel mailing list