async I/O (was: Is there a select()-like call for message queues?)

[Greg Hunt]

In article <11956 at smoke.BRL.MIL>, gwyn at smoke.BRL.MIL (Doug Gwyn) writes:
> In article <M+21-K2xds13 at ficc.uu.net> peter at ficc.uu.net (Peter da
Silva) writes:
> >> -Let's add 4 new system calls: aread, awrite, await, and status.
> >> -This doesn't break any existing programs, nor does it do any injury to
> >> -the design goals of UNIX.

[some comments removed for brevity]

> One thing that was appreciated in the computer science research community
> during the 1970s was that forcing applications to explicitly deal with
> asynchronism had been causing numerous reliability problems.  Thus when
> Tony Hoare published his paper on "Communicating Sequential Processes",
> it was acknowledged as a positive step toward shifting programming back
> into the relatively well-understood domain of sequential operations, with
> asynchronity managed by the underlying run-time support.  (This was an
> improvement over Per Brinch-Hansen's "monitor" concept, which still had
> the details of asynchronity too visible.)
> 
> UNIX loosely followed the CSP notion, wherein individual processes are
> strictly sequential but can communicate with concurrent processes to
> achieve controlled asynchronity.  The UNIX kernel manages the actual
> asynchronous operations and converts them into the per-process sequential
> I/O model.

[some comments removed for brevity]

I agree with the original poster - UNIX needs asynchronous reads and
writes (and lots of other commercial-grade features).

While the statement about the computer science research may be quite
true for the average client application, it is IMHO not true for systems
software, like database and transaction processing servers.  UNIX is
sadly lacking critical features for proper support of these, and other,
types of system software.  Such features have been available for years
and years in commercial-quality proprietary systems.  I am constantly
amazed that they do not exist under UNIX, and further amazed that many
folks don't seem to think that they are needed.  The research needs to
look at real world problems, and how they are solved, in addition to
solving pure research-oriented problems.  
IMHO, this problem is part of the reason that there are so many flavors
of UNIX.  Each vendor is adding extensions for those things that should
be there, but aren't.  It's a way to make money, but really messes up
being able to write sophisticated software easily in a portable fashion.

I'll get off my soapbox now.

--
Greg Hunt                   Internet: hunt at dg-rtp.dg.com
Data Management Development UUCP:     {world}!mcnc!rti!dg-rtp!hunt
Data General Corporation
Research Triangle Park, NC  Standard Disclaimer Applies