> The select() .vs. threads comparison does not match event-driven .vs.
> thread-oriented comparison because of the select() approach to deal with
> sorts of asynchronous IOs being just an hack that band-aided the badly
> designed UNIX system interface.
>
> When you plan to write a large application that will be very costly and
> that will be alive for a long time, you probably donnot want your design
> be polluted by considerations about the flaws of a thing like select()
> that should never have existed, if the UNIX system interface hadn't been
> so poor in the first place.
>
> Note that you can do things not too bad with select(2), if you can scale
> you application by doing multiple processes handling a not too high number
> of contexts.
>
> A good O/S must not constraint you to a design you donnot want for your
> application, but shall allow you to design your application as you think
> it will be the best possible.
>
> The thread-mania began with OS2. With this one (not two:) ), you were
> forced to use threads in order to deal with events asynchronously in your
> application. Even on this defunct OS, you could port mostly cleanly
> event-driven applications. The trick was to use some specialized threads
> that dealt with completions and kick ass the main thread appropriately.
> This was not perfect, but this allowed clean ports.
>
> To people that want to shoe-horn multiple threads in most applications,
> I will say: just think of your children that will have to maintain all
> these applications and you will probably review your opinion. ;-)
Select and poll are really the only mechanisms in Unix which permit event oriented
programming, so the difference between select vs threads and event vs threads is
hard to distinguish in Unix. That said, yes select and poll are both messy. You
need to set up a considerable amount of data each time you call select with a
large number of fds. The select trashes the data, and you must copy it all over
again. In the OS, where the select is processed, there is also a lot of messy
processing, and again when you scan the results. In fact if I scan the results
using the FD_ features provided, and then change to my own code using a little
assembly language to make use of bit scanning instructions, I can see a noticable
performance difference in my programs. Poll is even worse than select.
What is the alternative? You could certainly change select to improve it, but by
how much? A few extra routines in the library to handle the data more efficiently
would avoid the need to everyone to cook up their own solution. A change in the
format of the parameters could also help, but would it help enough to justify
breaking lots of existing code? However, compare this to what happens in other
systems, and it starts to look good. The event handling in MacOS and Windows may
look OK'ish from some points of view, but a lot of slow clunky stuff goes on
behind the scenes. At least select works for all I/O. The event handling in
Windows only works for some types of I/O, and, for example, using a serial port in
a complex program isn't practical without giving it its own thread. There are some
related serial I/O problems with Unix. POSIX is rather woolly in this area.
Different Unixen behave differently if you try to use non-blocking I/O on a serial
port with modem control. None of them behave sensibly using such I/O with a select
statement. Select definitely has problems here.
The first time I put a select based server together whose workload grew to several
hundred connections I thought I was heading for a performance disaster, because
select looks so klunky. In practice I have no problems. The key reason I never use
the message and semaphore IPC mechanisms in Unix is because they won't integrate
with select. In fact, if everything worked as well as select systems would be
excellent.
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/