Messages in this thread | | | Date | Wed, 26 Mar 1997 00:32:27 -0800 (PST) | From | Darren Senn <> | 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?
Yeah, timeout of 0, but no, not quite the same. Basically, it's the same thing: we periodically check to see if any data is available on the file descriptors that are important to us, and process the data if its there. The primary difference is if you have any number of file descriptors larger than 1. If you set nonblocking and read, then you have a system call overhead per file descriptor, regardless of whether there is data available or not. If you use a polling select(), then you have one system call overhead whether or not there's data (but just one: not one per file descriptor) plus one system call for each file descriptor that actually has data, but only when it has data. You get a big win using select() if you have, say, 100 file descriptors that only have data once every 30 times you check. But on the other hand, Ted's right that for most applications, you don't want to poll in the first place: if your primary task is calculation, kick a signal when data is available, and handle the file descriptor in the signal handler, but if your primary task is the file descriptors, then just go into a blocking select().
| |