OK. Checking the file descriptors after receiving an event is not
exactly polling in the I/O sense - but that's academic.
I actually have about 4 file descriptors, one running flat out, and the
others at serial line rates.
I think that we can close this thread.
Thanks all.
Daniel
Gilad Ben-Yossef wrote:
Daniel Feiglin wrote:
Thanks. The URL does not really answer my question, but I poked
around a bit on kernel-traffic.org.
My impression is, that select(3p) uses an internal event queue which
means that it is being triggered with a semaphore when a new event
arrives.
Can anyone confirm or say otherwise? (Or at the very least, that it's
not polling the file descriptors ...)
Yes and no - the way select works your user space application will
block (sleep) untill an event related to the file will arrive and then
will be woken up by the kernel (no exactly interrupt, just blocking)
but then glibc will scan the arrays of file descriptors to find out
what happened and on what file descriptors. I guess you can call this
"polling".
What you really want to do, especially if you have a lot of file
descriptors/events, is to use epoll()
Gilad
begin:vcard
fn:Daniel Feiglin
n:Feiglin;Daniel
email;internet:[EMAIL PROTECTED]
tel;work:972 9 8616204
tel;fax:972 9 8621052
tel;home:972 9 8320939
tel;cell:972 52 3869986
version:2.1
end:vcard
