Re: [LAD] LV2 realtime safe memory pool extension

2007/11/8, David Olofson <david@email-addr-hidden>:
> On Thursday 08 November 2007, Stefano D'Angelo wrote:
> [...]
> > 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.
>
> 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.

IIRC the TLSF allocator can do that.

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

Maybe because the host might want to keep track of memory allocations
(think about debug mode) or maybe it needs a rt-safe allocator too
(for example, the host can manage a network of plugins which can be
modified while it is running - maybe CLAM does that too)?

> > However, I see the atomic and sleepy version of allocate but only
> > one deallocate, why?
>
> 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.

Ah, ok. Understood :-)

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

Mmmm.. I guess it's not easy to resize the pool in a rt-safe way. And
even if you have some background thread doing it when it's needed, I
think it's very hard to do that while plugins are running, and so
allocating and modifying on that memory.

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

I agree.

Stefano
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Fri Nov 9 04:15:02 2007