On Sun, Feb 17, 2013 at 3:57 AM, M Donalies <[email protected]>wrote:
> No locks or mutexes in a callback function. I need to think about that one. > This is indeed a "lovely" topic for debate. I'm bound to say that, I'm currently doing a final-year project for college on the topic. I've came up with a solution, which I feel is the best balance between C++-y style Event classes, and C-style simple code. Simple is great for RT situations: its easy to see if something is RT or not. In essence it boils down to this: -Create an "EventBase" class with pure virtual type() and size() functions -Derive actual events like "EventPlay" overriding type() and size() -Create a ringbuffer checkout the example, it uses the JACK ringbuffer -Create events *on the stack* ie EventPlay eventPlay(); -Write events into the ringbuffer using jack_ringbuffer_write(); The last two steps are key, as they enfore the event gets *copied* into the ringbuffer, and the original goes out of scope (and gets destroyed). This solution is very workable, on the condition that only fundamental C datatypes are passed trough the Event class. Things will get nasty if you pass std::shared_ptr<> objects trough it, I've made that mistake already :) The following code shows communication from the GUI thread to the RT thread. Create another ringbuffer and functions for communicating in the other direction. https://github.com/harryhaaren/realtimeAudioThreading HTH, -Harry
_______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
