5 Nov
2011
5 Nov
'11
11:49 p.m.
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