Apple

Yes, you are probably right. When I originally started using this method, the local thread wake-ups were a LOT less common than incoming packets, so I did not want the overhead of adding another fd to every select. But, now that I am using with audio render callback the tradeoff may be different.

I also tried using kqueue/kevent, which has the advantage that you can change the filter set while it is waiting on the kevent. However, that introduced some sporadic system crashes on the iPhone, and I never could figure out exactly what I was doing wrong.

Tim

From: Paul Davis [mailto:email@hidden]
Sent: Wednesday, January 08, 2014 7:36 AM
To: Tim Dorcey
Cc: Lucas Ives; CoreAudio API
Subject: Re: scheduling a block from a render callback

On Wed, Jan 8, 2014 at 10:21 AM, Tim Dorcey <email@hidden> wrote:

I put the data on a non-blocking FIFO queue, then send a 0 length UDP packet to a non-blocking socket I am waiting on with select(). It happens that I want to process the audio in my network I/O thread that is already waiting on the select() so this was convenient. I missed the rule about not using anything in the BSD layer, but I don't think this has caused any problems.

i would probably avoid using UDP for this, because i think it has notably more internal (kernel) overhead than a POSIX FIFO ("pipe"), which you could add to the fd's used by select(2). but to each their own. really, mach ports are the lightest object for this on Darwin but apple is making it incrementally harder to use them.