Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!zaphod.mps.ohio-state.edu!wuarchive!uunet!lll-winken!arisia!sgi!shinobu!odin!elysium.esd.sgi.com!archer
From: archer@elysium.esd.sgi.com (Archer Sully)
Newsgroups: comp.unix.wizards
Subject: Re: Asynchronous I/O under UNIX
Message-ID: <2279@odin.SGI.COM>
Date: 28 Dec 89 02:13:05 GMT
References: <20880@pasteur.Berkeley.EDU> <932@crash.cts.com> <6679@lynx.UUCP>
Sender: news@odin.SGI.COM
Reply-To: archer@elysium.esd.sgi.com (Archer Sully)
Organization: Silicon Graphics, Inc.
Lines: 25

In article <20880@pasteur.Berkeley.EDU>, jas@postgres.uucp (James
Shankland) writes:
> In article <6679@lynx.UUCP> m5@lynx.uucp (Mike McNally) writes:
> >peterson@crash.cts.com (John Peterson) writes:
> 
> >... in fact, if I had threads, I don't think I'd
> >want or need a separate kernel-supported async I/O mechanism.
> 
> Yes!  I strongly agree, and it sure is nice to hear someone else taking
> this position.  I consider asynchronous I/O a hack to compensate for the
> absence of sufficiently lightweight processes.  Of course, one person's
> spartan elegance is another's semantic impoverishment, but I consider
> it a cleaner, clearer programming model.
> 
> jas

I've done this on IRIX (Silicon Graphics hacks....er IMPROVEMENTS to
SYSV :-), and it works ok.  Benefit turns out to be highly dependant 
on exactly what you are doing, and there are, of course, lots of funky
limitations, but it does work.

If anyone wants it I may even be able to dig it up.

Archer Sully 	  | A Mind is a Terrible thing to Taste
(archer@sgi.com)  |		- Ministry