Re: Waking up a network server: 2 threads + semaphore vs 1 thread + pipe
Re: Waking up a network server: 2 threads + semaphore vs 1 thread + pipe
- Subject: Re: Waking up a network server: 2 threads + semaphore vs 1 thread + pipe
- From: Joel Reymont <email@hidden>
- Date: Sat, 14 Feb 2009 14:56:39 +0000
My apologies for previous cross-posting!
The problem space is real-time audio generation on the iPhone (VoIP or
synthesized music) and the broadcast of said audio. The application is
supposed to send, receive, mix microphone with generated audio and do
it without stuttering. Imagine that the iPhone is an instrument and
you are trying to put together a distributed orchestra.
CoreAudio triggers a callback every few milliseconds to both ask for
audio and to supply it. I'm using ring buffers to store generated
audio and packets received from the network.
I will need to invoke sendto (or CFSocketSendData) in a loop to
deliver audio to clients but I don't think it's proper to do it from
within the CoreAudio callback.
I can wrap CFSockets around my native sockets and add them to the run
loop but it seems from reading the source code that CFSocket may run a
thread per socket. The "you can read" notification will be handled
then and I'll just need to run a thread to iterate through my sockets
and send the audio. I figure can wake up this thread from the
CoreAudio callback by using a semaphore.
Alternatively, I can track my sockets with select or kevent/kqueue and
use the same mechanism to track a pipe and wake the sending thread.
This will only require one thread since it will be woken up on both
sends (byte put into a pipe) and receives.
Which is the best design and how efficient?
How efficient is it to put a byte into a pipe in a callback that gets
triggered every few milliseconds? Would there be a significant gain
since an extra thread is not required to wait on a semaphore? Would it
even out since (intuitively) a pipe is slower?
Thanks, Joel
---
http://tinyco.de
--- Mac & iPhone
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macnetworkprog mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden