Thanks again for all the info, guys. I was only confused because I didn't
realize that select() and poll() blocked until I/O was available for some
reason, and I thought the majority of the time was spent in the program
loop, which is never the case for network programming.


On Wed, Oct 10, 2012 at 5:05 PM, Tamas Rudnai <tamas.rudnai@gmail.com>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 waiting
> for is triggered. Most of these function calls are ending up in an API ca=
ll
> which are OS primitives, going down to the IO layer. The scheduler then
> will know that the process / thread is waiting for something. The OS will
> not wake up the process unless a pocket has received for example. That
> leaves the CPU to do some real work other than just waiting for something
> to happen in a busy loop. In fact most program works like this: A 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 etc e=
tc
> etc... Try it out in a debugger, put a break point to the do_work() and s=
ee
> what happens...
>
> BTW: An OS with a preemptive scheduler still should be able to allow othe=
r
> processes to run even if one or more process is doing that tight infinite
> loop. In this case a timer tick interrupts the process, the scheduler get=
s
> the chance to decide if there is any other process to run, and makes a
> decision which one should get the next slice of CPU time. The problem is =
if
> a process like this is running on a very high priority or if that 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 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 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 appears
> > that all asynchronous network libraries somehow don't load up the CPU.
> Yes,
> > CPU load is the indicator of actual CPU load, and doesn't factor in
> > anything that's waiting on I/O, but shouldn't just the act of calling t=
he
> > 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
.