Subject: Re: [linux-audio-dev] Simple Plugin API: In/Out Ports
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: ti maalis 07 2000 - 21:52:27 EST
>> you (run time) link the plugins so that their calls to the malloc()
>> replacement does the required housekeeping, but that other parts of
>> the application are using a different function. i'm pretty sure that
>> this can be done with the linux run time linker, and if not, its just
>> a matter of a #define in the host application.
>
>I'm not sure this is safe to assume... It might be possible to solve
>for Linux (although it looks like a cludge to me to override
>"system" library calls for parts of on application), but I'm not sure
>if it's at all possible in other environments. AFAIK, a Windows DLL
>would dynamically link to the system DLL where the memory management
>stuff is. (Ok, Windows... But some people actually still care about
>it. ;-)
Well, I don't care about Windows in any way, shape or form, and I will
vehemently and vocally oppose any attempts to hamper an API so that it
can be easily or efficiently implemented on Windows by not using Linux
features.
However, even if I did, that just means you need a #define in either
the host or/and the plugin headers. No big deal.
>> Right, but the way I describe is what malloc(3) excels at. At least if
>> you get an SMP-friendly version like libhoard. malloc takes a lot of
>> crap, but its an incredibly highly evolved design that works very well
>> for many cases. its major breakdown is in cases involving large
>> numbers of sequential malloc/free calls involving small amounts of the
>> same sized memory (e.g. STL lists of char, arghhh.....). in the case
>> we're talking about, a generalized allocation routine for plugins to
>> use during their VST-would-call-it-process() function, then as long as
>> it doesn't call brk(2), its great.
>
>Well, brk is the little problem that an RT host has to be able to
>avoid... I just don't like the idea of forcing such implementations
>to rely on tricks with the dynamic library loader. Not all platforms
>are as flexible as UN*X.
Sure, but this has nothing to do with malloc. brk(2) is just the
underlying way that malloc gets more virtual memory to work with. on a
DOS system, some other method is used. in the type of RT host you're
describing, its important to basically *never* call the underlying
method while running plugins. None of that invalidates the very
efficient ways that malloc allocates the memory is managing. As I
said, malloc does fall down in some areas, but these are not likely to
be ones that plugins will use much, if at all; the default
implementations are also not very SMP/thread friendly, which is why
libhoard is important - its a malloc implementation that is extremely
SMP/thread friendly, and will run on more or less any platform with an
ANSI-ish C compiler.
I wasn't advocating that you just use the malloc in libc; what I was
advocating was the reuse of 99% of all the code from an existing
malloc implementation rather than coming up with some new attempt to
"make malloc better". Since this has been done at least a dozen times
by some very notable CS folk over the years, its pretty unlikely (not
impossible, just unlikely) that such an attempt will be fruitful.
The 1% that you alter is the part that calls brk(2) ... of course.
--p
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:23:28 EST