UNIX semantics do permit full support for asynchronous I/O

[Joshua Osborne]

In article <1990Aug30.222226.20866 at cbnewsm.att.com> lfd at cbnewsm.att.com (leland.f.derbenwick) writes:
>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.

Then that program is quite broken.  Unix guarantees no such thing.
If you want it you need to use fsync(filno), or open the file in
sync mode.  Currently Unix copys data to write into it's disk buffers,
returns controll to the user and doesn't write them until it is forced to
(sync, fsync, buffer shortage) or decides that it is a good time to write.

>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.

The default should be async for both read & write, because the default write
is aready async & the async read would be transparent.  There should be
a way to select sync read/write on a file by file basis 'tho.
-- 
           stripes at eng.umd.edu          "Security for Unix is like
      Josh_Osborne at 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