Messages in this thread | | | Date | Tue, 25 Mar 1997 23:04:41 -0800 (PST) | From | mdean <> | Subject | Re: >256 fd patch... |
| |
When you guys say "poll for data" are you implying that a timeout of 0 is passed to select? I don't see how that is useful, isn't that the equivalent of having the descriptors set non-blocking and just going in a loop trying to read single characters from them?
On Fri, 21 Mar 1997, Darren Senn wrote:
> > Ted said: > > Most importantly, select() isn't critical path code!!! If the execution > > time of select gets increased by (say) 20 or 40 cycles, no one is going > > to be able to notice the difference. We're talking nanoseconds > > here..... > > Ummmm. It may very well be that the author(s) of Linux select() did not > intend it to be used in a critical path. So be it. > > But remember that there are three ways to use select: > 1) Block indefinately until there's data on a file descriptor or > a signal comes in, > 2) Block for a finite period of time, or until data comes in, blah > blah blah, > and 3) Poll for data. > > While I agree that the large majority of code out there puts select() in its > top-level loop and uses methods 1 or 2, there is still quite a body of code > out there that uses the polling method at the very bottom of its innermost > loops. > > You can argue that this is a bad use of select(), or that those programmers > are hose-bags that clearly spend a great deal of time examining the insides > of their large intestines, and I might even agree with you. But I have > never seen a single select(2) man page that even implied that select() had > enough overhead as to render its use in an inner loop Evil(tm). So bad > use or not, you should expect that the code will be used that way. >
| |