> Shaul Karl wrote:
> > 
> > I found the last paragraph of subsection 12.1.1 of the "Linux Application
> > Development" (3rd edition) contradicting my knowledge. Am I right that it is
> > not accurate, or do I missing something essential?
> > 
> > Trying to quote the paragraph without copying the entire subsection, I get:
> > 
> > Although nonblocking I/O allows us to switch easily between file descriptors,
> > it has a high price. If it was up to the polling processes then they would
> > constantly be running - never blocks. Which inflicts a heavy performance
> > penalty on the system as the OS can never put these processes to sleep (try
> > running 10 processes like the one that was discussed previously and see how it
> > affects system performance).
> > 
> > "the OS can never put these processes to sleep"? - Perhaps in the Windows
> > world, but with Linux/Unix?
> 
> Quoting the late W. Richard Stevens in "UNIX Network Programming" (2nd
> ed, p. 145):
> "...The application is continually polling the kernel to see if some
> operation is ready. This is often a waste of CPU time..."
> So, of course, the book you quoted is accurate.
> 


I understand why "This is often a waste of CPU time...".
What I am failing to understand is that the "OS can never put these processes 
to sleep". If that is true then what about the kernel total control of the sys 
resources? What about the kernel always dividing sys resources among users 
according to sys policy?

I am still thinking that the assertion about "the OS can never put these 
processes to sleep" is not accurate. Am I wrong?
 

> If you're continually calling the kernel, how could it put your app to
> sleep? That's what they invented select/poll for.
> 


BTW: I should have said that the section of the book I was referring to was a 
preparation for their discussion about select. Basically, a process like the one
I am referring to is a demo process which does
        while (forever) {
                read(NON_BLOCKING I/O file descriptor)
        }



=================================================================
To unsubscribe, send mail to [EMAIL PROTECTED] with
the word "unsubscribe" in the message body, e.g., run the command
echo unsubscribe | mail [EMAIL PROTECTED]

Reply via email to