linuxaudio.org

--20cf305b0a56d23af504b104a128

Content-Type: text/plain; charset=ISO-8859-1
> Basically one "RtQueue" instance can pass messages back and forth between

quoted text
> 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

quoted text
> 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
--20cf305b0a56d23af504b104a128

Content-Type: text/html; charset=ISO-8859-1

Content-Transfer-Encoding: quoted-printable
> Basically one "RtQueue" instance can pass messages back and =

forth between

quoted text
> two threads lock free.

> I'd like to improve it so that one get / set method is there, and =

its

quoted text
> thread-aware so it will automatically push / pull to the right ringbuf=

fer.

quoted text
> But that's a touch hard for me as I'm using GLib threads and f=

inding which

quoted text
> thread is running is something i can't do yet :D

this approach re=

quires 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 representa=

ble as POD? The reason for this is so that when inserts happen the RT threa=

d 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 poin=

ters that needs to be avoided in the RT thread in case it blocks or gets st=

alled 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?<=

/div>

thanksIain
--20cf305b0a56d23af504b104a128--