2007/11/8, David Olofson <[EMAIL PROTECTED]>: > On Thursday 08 November 2007, Stefano D'Angelo wrote: > [...] > > 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.
IIRC the TLSF allocator can do that. > 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. Ah, ok. Understood :-) > 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 _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
