> Gerard Roudier wrote:
>
> > 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.
The performance problem, both from application and kernel viewpoints, when
a large number of resources is to be waited for, indeed affect
performances. Note that you may try to maintains bit/descriptor maps by
only applying differences when it is possible and, for the select() case,
you are not required to scan all bits if you keep track in your
applications of all active resources using some list for example. But this
is indeed a weak and poor optimization.
> 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
If the old semantic can be reproduced using some wrapper code, you donnot
break existing applications, but may-be you can affect performances a bit.
Note that sockets emulation over streams has already broken some
application in a subtle way. I know of applications that have been very
confused with some emulated getsockopt()/setsockopt() that had been
internally interrupted by some signal.
> 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.
Indeed.
> 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.
You can select on message queues on AIX, IIRC, but this is not portable.
MVS accepts additionnal parameters for the select() that allows to also
wait for events on other types of resources (in the case you really want
to use select under this O/S).
Using select() and une unique message queue for read is possible with
conjunction of SIGIO/SIGALRM with the risk of the application to lose time
if it has very bad luck.
You can implement something like that:
If you expect event(s) from fds (basically SIGIO will kick ass you)
1) set an alarm of a few seconds (<=2 seconds for example)
also set the alarm from the alarm handler.
2) get next message in blocking mode
3) if interrupted go with poll/select the fds
(can be either SIGIO or SIGALRM)
If you are so unfortunate that the SIGIO occurs between 1 and 2, your
program will only be stuck for less than 1..2 seconds.
(The period between (1) and (2) that may let msgrcv block can be minimized
by some additionnal code).
By the way, this works for me since 10 years in some applications, and I
never have been able to get the problem in my testings. Indeed it is not
clean and not optimal at all, but when you haven't the choice such a
band-aid is really helpfull.
Gérard.
-
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/