Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!usc!wuarchive!psuvax1!news
From: schwartz@groucho.cs.psu.edu (Scott Schwartz)
Newsgroups: comp.unix.internals
Subject: Re: UNIX semantics do permit full support for asynchronous I/O
Message-ID: <Fyu&?$-1@cs.psu.edu>
Date: 3 Sep 90 01:43:57 GMT
References: <60345@lanl.gov> <27619@nuchat.UUCP>
	<1990Sep1.185221.8718@eng.umd.edu> <555@siswat.UUCP>
	<27813@nuchat.UUCP>
Sender: news@cs.psu.edu (Usenet)
Organization: Pennsylvania State University, computer science
Lines: 13
In-Reply-To: steve@nuchat.UUCP's message of 2 Sep 90 17:26:33 GMT
Nntp-Posting-Host: groucho.cs.psu.edu


In article <27813@nuchat.UUCP> steve@nuchat.UUCP (Steve Nuchia) writes:
| >The POSIX.4 asynchronous I/O facilities are moving toward final ballot and
| >present a rich set of asynchronous I/O primitives.  These include the
| 
| It is precisely this "rich set" of "primitives" (!!!) that I am
| striving to avoid. 


I was just thinking the same thing.  Isn't it the case that
lightweight processes (mach style threads, say) with shared memory for
communication solve the asynch-io problem?  I'd prefer that to a new
set of async-io routines, I think.