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

Doug Gwyn gwyn at smoke.BRL.MIL
Tue Jan 16 15:37:21 AEST 1990


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.
>> Yes, it does!  Go back and read what I said in my previous message.
>I'm sorry, but other than the assertion that asynchronous I/O is itself
>a violation of the design goals I don't see anything that would lead to
>this conclusion. And I don't see that that, in and of itself, is a
>problem in the face of all the poor asynchronous I/O models that are
>spreading like gangrene through the UNIX world. At the worst it's a matter
>of choosing the lesser of two necessary evils.
>I mean you seem to agree that *allowing* asynchronous I/O is a good idea.
>Can you come up with a cleaner model? I'd love to see it.

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.

Rob Pike has shown in an article in a recent issue of Computing Systems
how the CSP model can be applied to graphical windowing environments,
with the result of dramatically simplifying the design of applications
in such environments.



More information about the Comp.unix.questions mailing list