8 Nov
2007
8 Nov
'07
7:22 p.m.
2007/11/8, David Olofson <david(a)olofson.net>et>:
Ah, ok. Understood :-)
On Thursday 08 November 2007, Stefano D'Angelo
wrote:
[...]
IIRC the TLSF allocator can do that.
I'm not a plugin developer and I have nothing
to do with LV2, but
anyway I think it can be a useful thing and that it is good to have
one "standard protocol" for this in LV2, instead of letting plugins
rely on external libraries or, even worse, include their own rt-safe
memory allocator.
Yes, that's exactly my point, but I think it needs to deal with
arbitrary size chunks to actually be able to serve that purpose in
real applications. To avoid plugins effectively allocating private pools
(just as if
they'd implemented it internally), a host would have to use a proper
real time memory manager, and then, whey not just make that available
directly to plugins?
Maybe because the host might want to keep track of memory allocations
(think about debug mode) or maybe it needs a rt-safe allocator too
(for example, the host can manage a network of plugins which can be
modified while it is running - maybe CLAM does that too)?
However, I see
the atomic and sleepy version of allocate but only
one deallocate, why?
Because it's never needed. When you free a memory block you're really
just saying "I don't need this any more", and you don't care if/when
the host does anything about it. BTW, are the blocking allocation calls intended for
background
threads...?
Wouldn't it be more useful with some interface that allows plugins to
request memory in a non-blocking manner, and if instant allocation
fails, have the host notify the plugin when the memory is available?
Basically, a malloc() call that means "If I can't have this memory
right away, please expand the pool so I can have it later!"
Mmmm.. I guess it's not easy to resize the pool in a rt-safe way. And
even if you have some background thread doing it when it's needed, I
think it's very hard to do that while plugins are running, and so
allocating and modifying on that memory.
The alternative would be to use the blocking version
only
in "background" threads, but unless you need background threads
anyway, to do actual work, this is just moving complexity into
plugins for no gain. If a plugin wants some memory to play around
with "in the near future", it shouldn't have to implement it's own
asynchronous memory management just to avoid stalling the host's
audio thread.
I agree.
Stefano