Xref: utzoo comp.lang.misc:5436 comp.unix.wizards:23724
Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!uwm.edu!zaphod.mps.ohio-state.edu!mips!pacbell.com!pacbell!att!cbnewsm!lfd
From: lfd@cbnewsm.att.com (leland.f.derbenwick)
Newsgroups: comp.lang.misc,comp.unix.wizards
Subject: Re: UNIX semantics do permit full support for asynchronous I/O
Summary: No.  This breaks existing programs.  But as an option...
Message-ID: <1990Aug30.222226.20866@cbnewsm.att.com>
Date: 30 Aug 90 22:22:26 GMT
References: <126800008@.Prime.COM> <60345@lanl.gov> <27619@nuchat.UUCP>
Followup-To: comp.unix.wizards
Distribution: usa
Organization: AT&T Bell Laboratories
Lines: 45

In article <27619@nuchat.UUCP>, steve@nuchat.UUCP (Steve Nuchia) writes:
> On the subject of asynchronous I/O in Unix:  I've come up with
> what I consider a rather slick way of making it fit neatly
> into Unix's way of doing things:
> 
> 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.
> 
> A user program that is not aware of the subterfuge will then run
> along for some (probably short) time and trap on an attempt to
> refill or inspect the buffer.  It will then be blocked until
> the request completes.  A savvy program will do something else
> for as long as it can, then take a peek at the buffer when it
> has run out of busy work.  One would probably also provide
> (grudgingly, in my case) an explicit call for discovering the status.

Apart from the implementation problems that others have mentioned,
_this suggestion breaks existing code_.

In essentially any serious database application, a completed
write() to a raw disk is treated as a guarantee that the data
block has been _physically written to the device_.  (This is
needed to ensure reliable transaction behavior in the presence
of potential system crashes.)  Since your suggestion would void
that guarantee, it is not benign.

On the other hand, I like your idea of implementing asynchronous
behavior using the ordinary read() and write() calls.  So how
difficult would it be to add a couple ioctl's to the existing
raw disk driver to support that?

One ioctl would select sync/async reads/writes (the default would
be the present behavior: sync read, sync write).  The other ioctl
would do the status inquiry.  With these, asynchronous behavior
is available on demand, and the OS doesn't need to jump through
any hoops to make it transparent: it's up to the user to use the
facility properly.

This is a lot cleaner than implementing asynchronous I/O in user
mode with shared memory and a background process...

 -- Speaking strictly for myself,
 --   Lee Derbenwick, AT&T Bell Laboratories, Warren, NJ
 --   lfd@cbnewsm.ATT.COM  or  <wherever>!att!cbnewsm!lfd