depending on the parameters you have set on the file descriptor, read=20 will block as well. You don't even _have_ to use select or poll. How you=20 do this while giving your application some time to do useful stuff (like=20 accept incoming connections) is between you and your architect. Tamas hit the nail on the head with his preemptive multitasking model=20 (which IIRC all 'modern' OS are) I know that Linux will also change nice=20 levels on CPU hogs so as time passes, they become deprioritized and=20 affect the rest of the system less. On 2012-10-11 07:36, V G wrote: > Thanks again for all the info, guys. I was only confused because I=20 > didn't > realize that select() and poll() blocked until I/O was available for=20 > some > reason, and I thought the majority of the time was spent in the=20 > program > loop, which is never the case for network programming. > > > On Wed, Oct 10, 2012 at 5:05 PM, Tamas Rudnai=20 > wrote: > >> It is because when you call the poll function it has a blocking >> mechanism, >> so the function call will not return unless the condition you are=20 >> waiting >> for is triggered. Most of these function calls are ending up in an=20 >> API call >> which are OS primitives, going down to the IO layer. The scheduler=20 >> then >> will know that the process / thread is waiting for something. The OS=20 >> will >> not wake up the process unless a pocket has received for example.=20 >> That >> leaves the CPU to do some real work other than just waiting for=20 >> something >> to happen in a busy loop. In fact most program works like this: A=20 >> text >> editor mostly waits for a user input, a web server watis for a new >> connection, a database waits for the file system to load the buffer=20 >> etc etc >> etc... Try it out in a debugger, put a break point to the do_work()=20 >> and see >> what happens... >> >> BTW: An OS with a preemptive scheduler still should be able to allow=20 >> other >> processes to run even if one or more process is doing that tight=20 >> infinite >> loop. In this case a timer tick interrupts the process, the=20 >> scheduler gets >> the chance to decide if there is any other process to run, and makes=20 >> a >> decision which one should get the next slice of CPU time. The=20 >> problem is if >> a process like this is running on a very high priority or if that=20 >> happens >> in a kernel module where there is no multitasking at all. >> >> Also a cooperative scheduler one cannot take over the CPU unless the >> process / thread gives that up. Therefore any infinite loop would >> completely block the entire OS (unless there is any API call within=20 >> it). As >> far as I remember MacOS up till version 9 was like that, also Novell >> NetWare, and many RTOS has cooperative scheduler too. Some has some=20 >> kind of >> watchdog to kill processes taking up CPU for too long. >> >> Tamas >> >> >> >> >> > >> > wouldn't it use 100% of the CPU's time in the main loop? But it=20 >> appears >> > that all asynchronous network libraries somehow don't load up the=20 >> CPU. >> Yes, >> > CPU load is the indicator of actual CPU load, and doesn't factor=20 >> in >> > anything that's waiting on I/O, but shouldn't just the act of=20 >> calling the >> > poll function in an infinite loop still fully load the CPU? >> > -- >> > http://www.piclist.com PIC/SX FAQ & list archive >> > View/change your membership options at >> > http://mailman.mit.edu/mailman/listinfo/piclist >> > >> >> >> >> -- >> int main() { char *a,*s,*q; printf(s=3D"int main() { char *a,*s,*q; >> printf(s=3D%s%s%s, q=3D%s%s%s%s,s,q,q,a=3D%s%s%s%s,q,q,q,a,a,q); }", >> q=3D"\"",s,q,q,a=3D"\\",q,q,q,a,a,q); } >> -- >> http://www.piclist.com PIC/SX FAQ & list archive >> View/change your membership options at >> http://mailman.mit.edu/mailman/listinfo/piclist >> --=20 http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist .