[opus] libopusfile's memory management.

[Timothy B. Terriberry]

alpha thinktink wrote:
> On Sat, Aug 24, 2013 at 7:56 PM, Timothy B. Terriberry
> <tterribe at xiph.org <mailto:tterribe at xiph.org>> wrote:
>
>     alpha thinktink wrote:
>      > is returning in tags handlers.  So of course when I call
>     opus_tags_clear
>      > or any other tags modification routine on an OpusTags struct with
>      > contents created by my call to malloc it throws an exception.
>
>     Yes, this doesn't work in Windows (it works everywhere else). You can't
>     use malloc/free across module boundaries unless both modules are linked
>     to the same DLL version of libc (static linking to libc also doesn't
>     work).
>
>
> Kinda figured as much but its very good to have a confirm.
>
>      > At the moment I've worked around it by loading and using MSVCRT.dll's
>      > malloc, calloc, realloc, and free but I have a feeling it's the wrong
>      > way to go about that.  I found it in the call stack trace when my
>      > debugger caught an application defined exception on the call to
>      > opus_tags_clear.
>
>     Well, the first question I would ask is, why are you malloc'ing your own
>     memory for an OpusTags structure? Is there some missing API that we
>     could provide that would just avoid the problem?
>     _______________________________________________
>
>
> I am mallocing my own memory for tags because I'm working in an
> extremely multi-threaded environment where if I'm not careful with what
> and how I CRIT_SECT shared data I can end up dead-locking, therefore,
> duplicating the OpusTags data was the safest (and fastest) way to share
> data amongst more than several threads.  The only other way I can think
> of to resolve this issue is to provide a tags duplication function: ie
> opus_tags_copy(OpusTags *_dst,const OpusTags *src) and other duplication
> functions for other structures as well (for the sake of completeness.)

Added in https://git.xiph.org/?p=opusfile.git;h=e96c5aa859f8;a=commitdiff

I'm holding off on adding copy routines for the other structures with 
internal allocations for now, since they are generally not mutable, and 
the application has better control over the lifetime. But let me know if 
you wind up needing one.