[LAD] RT-Safe UI/Engine Decoupling using Functional Programming and Reference Counted SmartPointers

[Stephen Sinclair]

The only thing that struck me is that I'm under the impression that
memory allocation and deallocation, even by the GUI thread, can cause
pauses to the whole process.  Hence, a threading model is not enough
for decoupling memory allocation pauses.  Can anyone comment on
whether this is true?  My impression is that at least a new or malloc
can stimulate a brk()/sbrk(), which will generate a page fault.  Not
sure about deallocations.

Of course, a pre-allocated object pool can deal with this.

Steve

On Sat, Aug 6, 2011 at 5:57 AM, Florian Paul Schmidt
<mista.tapas at gmx.net> wrote:
> On 08/06/2011 04:23 AM, Florian Paul Schmidt wrote:
>>
>> Hi,
>>
>> during the process of writing a new small jack sampler which fits my
>> workflow I came up with this little scheme to solve the UI/engine decoupling
>> problem. For the purpose of spreading the idea or alternatively getting
>> answers about how it's broken and sucks I decided to write a little article
>> describing it..
>>
>> http://178.63.2.231/~tapas/wordpress/?page_id=45
>>
>> The (largely unfinished and unusable) sampler project is here:
>>
>> https://github.com/fps/jass
>>
>> Let me have it..
>
> I guess I should mention the approach in a nutshell. Assiging a new
> generator (that plays a sample) to the first element of a std::vector of
> generators in the engine the UI would do e.g.:
>
> engine.commands.write(assign(engine.gens->t[0], p));
>
> where assign() is a function that builds a functor that dassigns the right
> argument to the left, p is a
>
> boost::shared_ptr<disposable<generator> >
>
> or with typedef
>
> disposable_generator_ptr,
>
> gens is a
>
> boost::shared_ptr<disposable<std::vector<boost::shared_ptr<generator> > > >
>
> or with typedefs:
>
> boost::shared_ptr<disposable<std::vector<disposable_generator_ptr> >
>
> or even shorter
>
> disposable_generator_vector_ptr
>
> Replacing the whole vector of generators with a new one (after e.g. loading
> a complete setup) wood look like:
>
> engine.commands.write(assign(engine.gens, v);
>
> where v would be a disposable_generator_vector_ptr.
>
> Just calling the set_sample member of a generator would look like this:
>
> engine.commands.write(&generator::set_sample, engine.gens->t[0]->t, s)
>
> where s is a disposable_sample_ptr..
>
> The ->t thingies show up, because every object is wrapped in a disposable<T>
> which has a member t that is the "payload"..
>
> I wonder if there's an even more elegant approach to cook down the verbosity
> a bit.. What you get, though, for the verbosity is the ability to call
> almost every member of every object in the engine's collection of objects
> without writing extra classes to define a command.. Such is the power of
> boost::bind and boost::function..
>
> Flo
>
> _______________________________________________
> Linux-audio-dev mailing list
> Linux-audio-dev at lists.linuxaudio.org
> http://lists.linuxaudio.org/listinfo/linux-audio-dev
>