In article <3DF7BD1E.CDF00...
David Schwartz <dav...
>"David M. Lloyd" wrote:
[ ... ]
>> When a select returns that a fd is ready, remove the fd from the set and
>> throw an event into the queue that states, for instance, fd "x" is ready
>> for reading, and go back to selecting again. Then have a pool of threads
>> reading from the queue and processing requests. After the threads read or
>> write to the appropriate fd, re-add the fd to the set using a mutex or
>> something, and then signal the thread that is selecting to reload its set
>> and select again (this is somewhat of a simplification but you get the
>> This way you only need one thread selecting, but all threads can operate
>> on the results of it.
> Imagine you're handling 1,000 connections and you find work to do on
>100 of them. You will wind up restarting the 'select' 100-ish times as
>you add each one back to the set. In most cases, you're better off
>reading all the data before restarting 'select'. (Not necessarily
>processing it, just reading it.)
Note that he said to remove the fd from the set, which means that it
won't be selected for again "for a while" (until signalled ready again).
Additionally, if you process *all* of the notified fds in the loop
before calling select again (which is the only sensible thing to do),
you won't go through the loop anywhere near 100 times unless the
connections readied at exactly the right (wrong) times.
That model works pretty well for medium large values of file
descriptors, though I prefer the optimization that any thread can be
in the select, and will yank off all of the fds into the queue, start
working on the first one, and broadcast a cv to let the other threads
pick stuff off of the queue. First one who finds the queue empty goes
back into select.
Steve Watt KD6GGD PP-ASEL-IA ICBM: 121W 56' 57.8" / 37N 20' 14.9"
Internet: steve @ Watt.COM Whois: SW32
Free time? There's no such thing. It just comes in varying prices...