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

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@email-addr-hidden> 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@email-addr-hidden
> http://lists.linuxaudio.org/listinfo/linux-audio-dev
>
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Wed Aug 17 20:15:01 2011