Re: [LAD] LV2 realtime safe memory pool extension

"Stefano D'Angelo" <zanga.mail@email-addr-hidden> writes:

> 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?

Because I dont see need for it. Even worse, I think it will add
complexity because each plugin would need to know if it allocated memory
during instantiation or afterward. In lv2dynparam I even use additional
abstraction that uses single allocation function with mode associated
with poll handle. pool is initally in sleey mode (during initialization)
and before starting to do real work it switches to atomic (i.e. not
sleepy) mode.

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