[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 17:26:52 CEST 2003

Am Samstag, 25.10.03 um 14:45 Uhr schrieb Marcus Comstedt:

> Max Horn <max at quendi.de> writes:
>> 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.
> Asynchronous I/O is nothing new or magical.  What you typically do is
> let the lower layer send a message to the upper layer when it's done,
> so that the upper layer knows that it can free or reuse the buffer.
> (In this case lower layer = mixer, upper layer = engine.)
Sure. So we store a callback instead of simply free'ing the memory. 
While I agree that is the more generic way, it really gains us almost 
nothing in this case. It gives a bit more flexibility at the cost of 
some more complexity. Guess it's a matter of taste whether one likes 
that tradeoff or not <shrug>.


>> 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.
> Transferring the ownership to the object is fine, as long as it is
> transferred back when the mixer is done with it.  It can be really
> simple:  The mixer calls a callback provided by the engine with the
> buffer as an argument, and then the engine can call free() on it if
> that is the right thing to do with it, or return it to its pool of
> free buffers or whatever it wants to do.
Yes we could do that. But *why* would we want to do that? So now we'd 
always have to pass a callback pointer (and define callbacks) whenever 
we want to play a sound, for the simple goal of allowing client code to 
use both new and malloc to allocate memory... erhm... I don't see the 
benefit in this case, to be frank, except from a purely abstract POV 

Anyway, I think discussing this point any further is rather pointless 
(but don't let that stop you from a reply :-)


More information about the Scummvm-devel mailing list