Re: [LAD] LV2 realtime safe memory pool extension

On Thursday 08 November 2007, Stefano D'Angelo wrote: [...] 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? 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!" 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. //David Olofson - Programmer, Composer, Open Source Advocate .------- http://olofson.net - Games, SDL examples -------. | http://zeespace.net - 2.5D rendering engine | | http://audiality.org - Music/audio engine | | http://eel.olofson.net - Real time scripting | '-- http://www.reologica.se - Rheology instrumentation --'