<div class="gmail_quote">On Thu, Nov 3, 2011 at 1:39 PM, Paul Davis <span dir="ltr"><<a href="mailto:paul@linuxaudiosystems.com">paul@linuxaudiosystems.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
no, using a protocol like OSC doesn't solve the basic problem: making<br>
changes to data structures used by the RT code when those changes<br>
can't be done with RT constraints<br></blockquote><div><br>Yes, sorry must not have made myself clear :)<br><br>Currently using the jack ringbuffer as a RT queue. Thought of a nice abstraction of the "one way only" problem too:<br>
Just wrap two ringbuffers into a single class, and then have two set / get functions.<br><br>Basically one "RtQueue" instance can pass messages back and forth between two threads lock free.<br>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<br>
<br>-Harry<br></div></div>