> 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
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Sun Nov 6 00:15:01 2011
This archive was generated by hypermail 2.1.8 : Sun Nov 06 2011 - 00:15:01 EET