Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!spool.mu.edu!samsung!zaphod.mps.ohio-state.edu!maverick.ksu.ksu.edu!ux1.cso.uiuc.edu!news
From: mcdonald@aries.scs.uiuc.edu (Doug McDonald)
Newsgroups: comp.arch
Subject: Re: Ignorance speaks loudest (was:Computers for users not programmers)
Message-ID: <1991Feb7.161500.15856@ux1.cso.uiuc.edu>
Date: 7 Feb 91 16:15:00 GMT
References: <1991Feb6.175555.18281@cs.cmu.edu> <1991Feb4.210853.22139@odin.corp.sgi.com> <1652@hpwala.wal.hp.com> <409@bria> <13252@lanl.gov> <1991Feb4.154607.8606@ux1.cso.uiuc.edu> <1991Feb5.020456.1119@ux1.cso.uiuc.edu>
Sender: news@ux1.cso.uiuc.edu (News)
Organization: University of Illinois at Urbana
Lines: 33


In article <1991Feb6.175555.18281@cs.cmu.edu> bsy+@cs.cmu.edu (Bennet Yee) writes:
>In article <1991Feb5.020456.1119@ux1.cso.uiuc.edu> mcdonald@aries.scs.uiuc.edu (Doug McDonald) writes: (DM2)

[I describe one version of async IO]

>It seems to me that this computation model is not that good.
Really, ist is just fine.

>
>A better one, perhaps, is one where your task has two (or more) threads, of
>which one can be CPU bound and the other handle your (slow) disk I/O,
>blocking if nec'y.  It's more general, and the kernel does NOT have to
>understand the calling conventions of your language implementation to invoke
>the completion routine.
>
>To emulate the style advocated by DM, the I/O thread is just created at the
>call and terminated after it invokes the completion routine.
>

Yep, that is just fine too, and nicely extensible. 



>
>[ Isn't this newsfroup supposed to be moderated or something?  



No.


Doug McDonald