> > > model or a more
> > > complicated model using nonblocking I/O with select()/poll().
> >
> > Where poll()/select() is applicable it's very efficient, and in most of
> > cases easy to use unless the concept is completely foreign to the
> > programmer.
>
> Poll or select w/ nonblocking IO in server applications can get quite complex.
> I've seen examples of identical servers written with process pools, thread
> pools, and nonblocking IO(w/ select). The nonblocking versions were by far
> the largest and most complex. But interestingly enough, they were also the
> fastest!
Eh? If you use select or poll directly your code can get a bit messy. However, if
you build an event oriented library on top of select you can cook up simple elegant
servers very quickly. I've been doing it for years.
Threads mean lots of asynchronous behaviour. Asynchronous behaviour means major
testing problems. The asynchronous behaviour in select based servers is much more
limited, so their testability is much better. I can cook up simple servers based on
my event library in a few hours, and they run reliably. A threaded application
couldn't be tested well in that time.
Of course, a select based application won't scale to multiple CPUs, but for a
single CPU environment nothing beats it for simplicity, testability, or - as you
point out - performance.
Steve
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/