I\'m working through a chapter about iPhone audio and have come across a section of code that I can\'t make sense of:
while (aqc.playPtr < aqc.sampleLen)
Well, sleep(3) may be implemented by using signals. It depends on the platform.
When you use select(2) and poll(2), you know that no signals will be involved, which is often very useful. For example, if you are using alarm(2), you should not use sleep(3) as well, because "mixing calls to alarm and sleep is a bad idea" (according to the man page.)
Also, select and poll give you millisecond granularity when sleeping, but sleep only has a granularity in terms of seconds.
There's no reason to do it. There's no reason ever to Sleep() either. One should always be expecting at least one event - program shutdown request.
Select allow for accurate sub second wait, and is more portable than sleep. There are other ways to wait, see this question.
But the timeout parameter of select should not be a float but a pointer to struct timeval. I'm surprised the code you show even compiles. More : this strange conditional select is followed by an unconditional sleep(1). Looks pointless to me.
The real reason to use 'select' instead of 'sleep' is the accuracy of sleep, especially the audio or video playback. Use 'select' can get higher precision time interval for sleeping on linux or windows or other OS than 'sleep'.
I am surprised that many people actually don't know why. And please stop to shame on the programmer / write of such a code.
Using select()
with NULL
rfds
, wfds
and efds
is an idiomatic way of portably sleeping with subsecond resolution.
When you use SIGALM signal in your application and you use (u)sleep
functions, when SIGALRM occurs program immediately return from sleep function, so the best way to sleep is to wait on select
function.
struct timeval tv;
tv.tv_sec = 1;
tv.tv_usec = 1000;
do
{
ret = select(1, NULL, NULL, NULL, &tv);
}
while((ret == -1)&&(errno == EINTR)); //select is interruped too