[LAD] LV2 realtime safe memory pool extension

[Nedko Arnaudov]

David Olofson <david at olofson.net> writes:

> On Monday 05 November 2007, Nedko Arnaudov wrote:
>> Purpose of this LV2 extension is to standardize realtime safe
>> allocations in a plugin. Plan is, host to provide functions that
>> plugin can call. Pointers to functions are provided through host
>> feature. Only memory pool (fixed chunk size) functionality is
>> defined.
>> 
>> Attached is early draft of the header. Doxygen generated from it
>> documentation is available at:
>> 
>> 
> http://svn.gna.org/viewcvs/*checkout*/lv2dynparam/website/doxygen/lv2__rtmempool_8h.html
>> 
>> Any comments are welcome. In particular about whether general
>> purpose allocator (arbitrary memory chunk size) should be part of
>> this same extension.
>
> I'm not quite sure I see the point of having hosts provide this level 
> of functionality. A pool of fixed size chunks is trivial to implement 
> on the plugin side.
>
> The only obvious advantage I see is the potential transparent host 
> side sharing of memory across plugins - but this gets tricky to 
> implement when plugins request different chunk sizes. Sure, the host 
> can split and merge chunks and stuff as needed, but then you may as 
> well go all the way, as you'll need a real memory manager behind the 
> scenes anyway.

The point is that some plugins need *realtime safe* memory allocation. I
need this functionality for lv2zynadd plugin (like arbitrary voices
count allocation) and for lv2dynparam plugin library internal operation
too. There were rumors in #lad that such functionality may be useful
without lv2dynparam extension. This has lead to this proposal. But if
there are no positive opinions for this extension I'll integrate it into
lv2dynparam extension.

That reminds me that LV2 may need a way to specify optional features
that interdepend. I.e. features (extensions) A and B are both optional
but if A is provided B is required. Of course plugin can check this
explicitly on instantiate and refuse to use feature, but I'm not sure
how vital is such approach.

-- 
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: not available
URL: <http://lists.linuxaudio.org/pipermail/linux-audio-dev/attachments/20071108/d9499dbd/attachment.pgp>