Correction 5 fd's
I have 3 serials, one socket and one proprietary high speed thingy (less
than 1kb per read, once every millisec).
My strategy is to have each fd read into a bit of shared memory, post a
"got something" semaphore and return. You do it with 5 little if()
paragraphs (error handling aside), reset the read bit mask (always the
same) and back to select.
(I'm leaving out multiple buffer management for now.)
I want to use a separate service task for the high speed thingy and
service tasks or threads (TBD) for the rest.
Most of the time select() will exit with one descriptor to service - the
high speed thingy.
epoll(): I just looked at the man page for the first time. That's now
"on notice".
Multithreading/tasking: I used select with both a while back. Rather
than breaking my teeth, I found it quite "comfortable" to work with
after getting the hang of it. I am also looking at a
multithreading/tasking option using RTAI or RTL for the "thingy" but
that's way OT, and I don't want to get into that for now.
Daniel
Amos Shapira wrote:
On 14/06/06, Daniel Feiglin <[EMAIL PROTECTED]> wrote:
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.
Do you mean you have 4 FD's pointing at sources of the same type
(sockets,
pipes) and one of them transfers data faster than the others? Or do you
mean that you have three descriptors of actual physical serial lines
vs. one
descriptor of a faster source?
If the former then could it be that you handle only one descriptor at
a time
between polls? Do you make sure to handle ALL "1" bits in the
returned mask
before finishing the iteration and going back to select()?
I'd subscribe to Gilad's recommendation for direct call to epoll() -
at least back
in the old kernels of UNIX and Linux there was a huge amount of setup and
tear-down involved in every single call to select() that just wasn't
required with
poll() and friends (since poll's input parameters basically preserved
the required
state to start a call immidietly).
Another possibility is to use multi-threading and be done with select
and such -
select() was designed when threads weren't quite a real option. These
days with
light threads context switch and easy access to multi-core there is
less reason to
"break your teeth" on using select.
I think that we can close this thread.
I'm still curios, if you don't mind.
--Amos
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
