[vorbis-dev] vorbisfile close and memory callbacks
Michael Smith
msmith at labyrinth.net.au
Mon Oct 23 16:09:27 PDT 2000
At 07:58 PM 10/23/00 +0100, you wrote:
>> > This is just wrong, it's not extensive work (far less than the double to
>float changeover :)
>>
>> ...which was absolutely necessary to alleviate pressure on the data cache,
>not
>> just an interface nicety. And I'm still, a month later, dealing with
>> occasional fallout from that change. Double->float took two hours.
>Repairing
>> two vital encode algorithms to not choke on the reduced resolution took
>> another month. I've still not cleaned up all the compiler warnings.
>
>changing from double->float is problematic yes because of the complexities
>you state.. search and replace of malloc with if (malloccallback)
>malloccallback(..); else malloc(..); ... isnt
However, the major API changes this also requires would be rather complex.
If you're going to provide for callbacks, you obviously have to provide a
method to actually tell the library what your callbacks are. And they have
to propagate to _every_ function which might allocate or free memory.
Hardly trivial.
>this ISNT an interface nicety.. its essential for systems that need to use
>memory pools and replace bad memory managers that come with some compilers
>(ie consoles) that can have bad fragmentation, no garbage collection and
>slow allocation schemes. (basically we will just have to search and
>replace the code ourself on a local copy if this isnt done)
No, it's an interface nicety. Replacing malloc/free/etc. may well be
essential for some systems. Doing that through callbacks at runtime is, as
far as I can see, NOT required. Is there anything that would make it
difficult or impractical to simply compile libvorbis with #define malloc(x)
special_magical_malloc_func(x), and so on? Is there a _real_ reason why
you'd have to choose between multiple different malloc schemes at runtime?
This is slightly more work than replacing malloc/etc with linker magic, but
does allow you to treat libvorbis seperately and have its own allocation
functions. It's simple, too. It'd take about 20 seconds to add to an
appropriate header file, then you'd just have to recompile.
Michael
--- >8 ----
List archives: http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to 'vorbis-dev-request at xiph.org'
containing only the word 'unsubscribe' in the body. No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.
More information about the Vorbis-dev
mailing list