[LAD] LV2 realtime safe memory pool extension

[David Olofson]

On Thursday 08 November 2007, Krzysztof Foltman wrote:
[...]
> It would also facilitate sharing memory pools between plugins. On
> the other hand, it might sometimes make sense to have separate pools
> per plugin, to improve cache locality.

Unless you're running the plugins on different cores or CPUs, wouldn't 
separate pools just hurt, no matter what...? Cache locality is the 
very reason why you *don't* want statically allocated per-plugin 
buffers for audio transfer and stuff like that.

Do you have a specific example where per-plugin pools would improve 
things?


> But if my opinion counts, please provide a LGPL-ed reference
> implementation (based on TLSF or anything else that works :) ) and
> test suite as well :) So that host authors can simply use them to
> avoid bugs and duplicated effort.

Yeah, that's why I suggested TLSF. :-)

Now, there are two issues with the TLSF implementations I know of:
	1) They don't support resizing the pool on the fly.
	2) They don't support 64 bit environments.

The latter should be easy to fix, I think (use sizeof(void *) for 
alignment, basically), but resizing the pool might require some 
redesign of the algorithm.

I'll need a hard RT memory manager that deals with both of these 
issues for my EEL scripting engine, so I'm rather interested in this 
particular issue, whether or not it goes into an LV2 extension.

[...]


//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  --'