lkml.org 
[lkml]   [1997]   [Mar]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: >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.
>


\
 
 \ /
  Last update: 2005-03-22 13:39    [W:0.092 / U:1.276 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site