[LAD] Inter thread Communication: Design Approach

Harry van Haaren harryhaaren at gmail.com
Fri Sep 2 11:59:09 UTC 2011


On Fri, Sep 2, 2011 at 9:36 AM, Florian Paul Schmidt <mista.tapas at gmx.net>wrote:

> Hmm, i used Functors and Closures in jass for passing commands to the
> realtime thread and wrote a small article about it.
>

Cheers for the link, I've browsed it before I think, consider yourself
"blog-famous" :D

 Indeed the functor system will work, but I find the syntax quite clumsy,
and I don't want the GUI to become non-responsive until the Engine signals
the event is done. Reason for this is that there's quite an amount of events
going back and forth, and I estimate the GUI will become too laggy to feel
right.

While I could do some (nasty) event checking and not in general, only
blocking when I know I'm changing the state of an EngineElement that I need
a reference to. Again quite nasty IMO. The other problem is that since all
communication is OSC, I cannot guarantee that all "controller" or "view"
programs (ie OSC senders / receivers) will comply. So I need a "foolproof"
plan, where *any* messages can be sent in *any* order, without crashing /
hiccups.

Your mention of "poor man's garbage collection" is quite a do-able system,
and I like how it automatically abstracts the non-RT actions away from the
RT thread. (ie: removing samples from mem etc) Will let you know if I ever
get around to doing it... Currently I'm just storing all samples ever used
in mem... and praying somebody doesn't load a 2GB .wav file :D

<http://www.codeproject.com/KB/cpp/fastdelegate2.aspx>  for example.
> (I used Don's original "Fastest Possible C++ Delegates" on an embedded
> project years ago -- worked great).


Nice article there... seems a clean enough implementation. Perhaps if I
decide a on a rewrite of the event handling at some state I'll concider this
as an option :)

-Harry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxaudio.org/pipermail/linux-audio-dev/attachments/20110902/116ae6ce/attachment.html>


More information about the Linux-audio-dev mailing list