Xref: utzoo comp.lang.misc:5433 comp.unix.internals:8
Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!uunet!wuarchive!udel!haven!mimsy!mojo!stripes
From: stripes@eng.umd.edu (Joshua Osborne)
Newsgroups: comp.lang.misc,comp.unix.internals
Subject: Re: UNIX semantics do permit full support for asynchronous I/O
Message-ID: <1990Aug30.194702.15961@eng.umd.edu>
Date: 30 Aug 90 19:47:02 GMT
References: <27619@nuchat.UUCP> <61535@lanl.gov>
Sender: news@eng.umd.edu (The News System)
Distribution: usa
Organization: College of Engineering, Maryversity of Uniland, College Park
Lines: 40

In article <61535@lanl.gov> jlg@lanl.gov (Jim Giles) writes:
>From article <27619@nuchat.UUCP>, by steve@nuchat.UUCP (Steve Nuchia):
[...]
>> Have read(2) and write(2) calls map the pages containing the buffers
>> out of the user address space and return immediately.  Once the
>> data have been copied (DMAed?) to/from the buffers, map the pages back in.
>> [...]
>
>Yes, this will work.  I believe that MACH already does this.
>Unfortunately, this idea has two problems: 1) [omited]
>2) not all I/O requests are a multiple of the pagesize.
>The pagesize problem
>just means that you'd have to map out more memory than is actually
>involved in the I/O request.  This means that the user might get
>blocked on memory that is really perfectly safe to access - a minor
>source of slowdown.

It shouldn't be a source of slowdown in the read case; normally the program
would not get control untill after the read was done, the new worst case is
exactly the same.  However for reads the old best case is far better then
the new worst case, and it could happen relitavly offen.

The old best case: do a large write, the kernel copys the data lets you run
and writes it some time, you re-use the buffer.

If you do that under the new system:  You do the large write the kernal maps
out the pages,  gives you control you re-use the buffer, the kernel makes you
sleep untill it can do the write.  You lose out.  Alot of programs do this.
Currently stdio does this.  Of corse stdio would need a bit of tweeking anyway.
(allign page sized buffers on page boundrys)  While we are in there we could
make writes use 2 page buffers, and flush alterniate ones...  and do huge
writes directly out of the users space.

(just things to think about, I do like the idea...)
-- 
           stripes@eng.umd.edu          "Security for Unix is like
      Josh_Osborne@Real_World,The          Mutitasking for MS-DOS"
      "The dyslexic porgramer"                  - Kevin Lockwood
"Isn't that a shell script?"                                    - D. MacKenzie
"Yeah, kinda sticks out like a sore thumb in the middle of a kernel" - K. Lidl