> 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 ...

Just wondering if I can get a clarification, this is the internal audio/sequence data for the engine that needs to be representable as POD? The reason for this is so that when inserts happen the RT thread is not dealing with memory management for a linked list? Am I correct in understanding that it's the memory allocation part of creating new pointers that needs to be avoided in the RT thread in case it blocks or gets stalled by the OS?

Does this mean that if I can get away with some kind of data scheme for the engine that is not dependent on the pointer management that it will be a lot easier to update based on incoming queued messages?

thanks
Iain