> Mike Harrelson wrote:
>
> > > > 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.
And what if you have to interact with something through a library, such as a
database API? You can't use select/poll, nonblocking/async IO in those cases
since you don't have direct access to the underlying IO mechanisms.
> 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.
Depends on the design. I can see how threaded applications can be difficult
to test and debug, especially with a dirth of good thread aware debuggers.
Most things have their drawbacks I suppose.
-- mikeh
-
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/