14 May
2010
14 May
'10
1:36 a.m.
On Thu, May 13, 2010 at 6:10 PM, Fons Adriaensen <fons(a)kokkinizita.net> wrote:
On Thu, May 13, 2010 at 05:27:33PM -0400, Stephen
Sinclair wrote:
Thanks for the reply! Now, just wondering a last thing about (1)
then, how might operations like read() in one thread affect another,
if at all? For example, if I use a separate thread to read from a
pipe or socket, and pass it through a ring buffer to the audio
callback, is that the right way? The thread will happily block on
read without somehow causing problems elsewhere?
I'm wary because I understand that some operations can affect a whole
process if you're not careful, even if you're using threads. (Like
memory page misses and malloc.)
Steve
1) Have a secondary thread responsible for
passing data to the audio
callback through a wait-free ring buffer.
2) Read from a pipe, FIFO, or socket from another process (e.g.
popen), using select() or poll() to check when there is actually data
to read.
3) Read from a file, using select()?
4) The async I/O API.
5) Interprocess shared memory, presumably using a semaphore of some
kind. I guess this is similar to (1) but for inter-process
communication.
(1) is the correct way. (5) may work if the other process and
the way you talk to it are up to the task, that is if it just
emulates (1) with the sender being another process.
(2),(3),(4) are all real-time unsafe.