Re: [LAD] LV2 realtime safe memory pool extension

2007/11/8, Nedko Arnaudov <nedko@email-addr-hidden>:
> David Olofson <david@email-addr-hidden> 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.

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.

However, I see the atomic and sleepy version of allocate but only one
deallocate, why?

> 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>
>
> _______________________________________________
> Linux-audio-dev mailing list
> Linux-audio-dev@email-addr-hidden
> http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
>
>
>
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Thu Nov 8 16:15:02 2007