lkml.org 
[lkml]   [1997]   [Mar]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: >256 fd patch...

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.

\
 
 \ /
  Last update: 2005-03-22 13:39    [from the cache]
©2003-2014 Jasper Spaans. hosted at Digital Ocean