Of course we've had select() since BSD 4.2 and poll() since System V
or so, and they work reasonably well for asynchronous I/O up to a
hundred or so channels, but suck after that; /dev/poll (available in
Solaris and Linux) is one approach to solving this; Linux has a way to
do essentially the same thing with real-time signals, and has for
years; and FreeBSD has kqueue.
More details about these are at
http://www.citi.umich.edu/projects/linux-scalability/
None of this helps with disk I/O; most programs that need to overlap
disk I/O with computation, on either proprietary Unixes or Linux, just
use multiple threads or processes to handle the disk I/O.
POSIX specifies a mechanism for nonblocking disk I/O that most
proprietary Unixes implement.  The Linux kernel hackers are currently
rewriting Linux's entire I/O subsystem essentially from scratch to
work asynchronously, because they can easily build efficient
synchronous I/O primitives from asynchronous ones, but not the other
way around. So now Linux will support this mechanism too.
It probably doesn't need saying for anyone who's read Beberg saying
things like "Memory management is a non-issue for anyone that has any
idea at all how the hardware functions," but he's totally off-base.
People should know by now not to take anything he says seriously, but
apparently some don't, so I'll rebut.
Not surprisingly, the rebuttal requires many more words than the
original stupid errors.
In detail, he wrote:
> Could it be? After 20 years without this feature UNIX finally
> catches up to Windows and has I/O that doesnt [sic] totally suck for
> nontrivial apps? No way!
Unix acquired nonblocking I/O in the form of select() about 23 years
ago, and Solaris has had the particular aio_* calls we are discussing
for many years.  Very few applications need the aio_* calls ---
essentially only high-performance RDBMS servers even benefit from them
at all, and most of those have been faking it fine for a while with
multiple threads or processes.  This just provides a modicum of extra
performance.
> OK, so they do it with signals or a flag, which is completely
> ghetto, but at least they are trying. Keep trying guys, you got the
> idea, but not the clue.
Readers can judge who lacks the clue here.
> The Windows I/O model does definately [sic] blow the doors off the
> UNIX one, but then they had select to point at in it's [sic]
> suckiness and anything would have been an improvement. UNIX is just
> now looking at it's [sic] I/O model and adapting to a multiprocess
> multithreaded world so it's gonna be years yet before a posix API
> comes out of it.
Although I don't have a copy of the spec handy, I think the aio_* APIs
come from the POSIX spec IEEE Std 1003.1-1990, section 6.7.9, which is
13 years old, and which I think documented then-current practice.
They might be even older than that.
Unix has been multiprocess since 1969, and most Unix implementations
have supported multithreading for a decade or more.
> Bottom line is the "do stuff when something happens" model turned
> out to be right, and the UNIX "look for something to do and keep
> looking till you find it no matter how many times you have to look"
> is not really working so great anymore.
Linux's aio_* routines can notify the process of their completion with
a "signal", a feature missing in Microsoft Windows; a "signal" causes
the immediate execution of a "signal handler" in a process.  By
contrast, the Microsoft Windows mechanisms to do similar things (such
as completion ports) do not deliver a notification until the process
polls them.
I don't think signals are a better way to do things in this case
(although I haven't written any RDBMSes myself), but you got the
technical descriptions of the two operating systems exactly backwards.
Most programs that use Linux real-time signals for asynchronous
network I/O, in fact, block the signal in question and poll the signal
queue in a very Windowsish way, using sigtimedwait() or sigwaitinfo().
--
<kragen@pobox.com>       Kragen Sitaker     <http://www.pobox.com/~kragen/>
Edsger Wybe Dijkstra died in August of 2002.  This is a terrible loss after
which the world will never be the same.
http://www.xent.com/pipermail/fork/2002-August/013974.html