RT-Safe UI/Engine Decoupling using Functional Programming and Reference Counted SmartPointers
6 Aug
2011
6 Aug
'11
4:23 a.m.
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..
Regards,
Flo
6 Aug
6 Aug
11:57 a.m.
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
17 Aug
17 Aug
6:39 p.m.
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(a)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(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
6:43 p.m.
On Wed, Aug 17, 2011 at 12:39 PM, Stephen Sinclair <radarsat1(a)gmail.com> wrote:
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.
page faults affect kernel tasks (threads), not processes. the affected
task will block but other tasks in the same process will be able to
execute without delay.
i believe.
4646
days inactive
4657
days old
linux-audio-dev@lists.linuxaudio.org
3 comments
3 participants
participants (3)
-
Florian Paul Schmidt -
Paul Davis -
Stephen Sinclair