On Thu, Nov 3, 2011 at 4:02 PM, Harry van Haaren <[email protected]> wrote: > On Thu, Nov 3, 2011 at 1:39 PM, Paul Davis <[email protected]> > wrote: >> >> no, using a protocol like OSC doesn't solve the basic problem: making >> changes to data structures used by the RT code when those changes >> can't be done with RT constraints > > Yes, sorry must not have made myself clear :) > > Currently using the jack ringbuffer as a RT queue. Thought of a nice > abstraction of the "one way only" problem too: > Just wrap two ringbuffers into a single class, and then have two set / get > functions. > > Basically one "RtQueue" instance can pass messages back and forth between > two threads lock free. > I'd like to improve it so that one get / set method is there, and its > thread-aware so it will automatically push / pull to the right ringbuffer. > But that's a touch hard for me as I'm using GLib threads and finding which > thread is running is something i can't do yet :D
this approach requires that all your data structures can be representable as POD (plain old data) and be effectively and easily de/serialized from/to a bytestream. this can be quite restrictive. linked lists, for example ... _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
