Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!bloom-beacon!think!ames!lll-tis!ptsfa!hoptoad!academ!uhnix1!sugar!peter
From: peter@sugar.UUCP (Peter da Silva)
Newsgroups: comp.sys.amiga
Subject: Re: Transparent Asynchronous I/O.
Message-ID: <682@sugar.UUCP>
Date: Thu, 10-Sep-87 08:30:17 EDT
Article-I.D.: sugar.682
Posted: Thu Sep 10 08:30:17 1987
Date-Received: Sat, 12-Sep-87 16:31:44 EDT
References: <514@sugar.UUCP> <4160003@hpspdla.HP.COM> <1675@sputnik.COM>
Organization: Sugar Land UNIX - Houston, TX
Lines: 51

In article <1675@sputnik.COM>, kurt@tc.fluke.COM (Kurt Guntheroth) writes:
> If the program doesn't wait for the I/O to finish
> 
> 1.  Don't you loose one good place for a context swithc, and therefore have
>     a weaker multitasking?

No. Once the program has sent the packet to the DOS handler it will still
do a normal WaitIO and therefore context switch. It's just that DOS will
have already pre-read the block (sequential reads make UNIX preload the
next block... I would expect any similar system to at least do this much),
or will immediately respond before writing the block (it really does this
already on a close, which is why you need to watch that little red light
instead of depending on what the program says).

Also, if the write queue is full or the readahead isn't finished you'll still
wait.

> 2.  How do you know an I/O operation has failed?  You don't get a return
>     code since you didn't wait for the I/O to finish.  You would get some
>     asynchronous interrupt saying "I/O operation failed on some port some
>     time in the past."  Diagnosis will be a major pain.

You don't care. If it's on a read, the DOS just notes that the next sequential
block is bad and your program sees an error at that point. If it's on a write,
DOS just relocates the block it's writing without telling you... you don't
care anyway. If it's a disk full on a write DOS already knows this and tells
you right away.

The only situations I can see where this would be a problem are:

	1: disk is almost full and the write fails.

	solution: keep a couple of blocks around for a ripcord, just like
	RAM: does with its 30K of memory. Some hard disks keep 1 sector per
	track for this purpose. You still want to pop up the error requestor
	so the user knows his disk is going belly up.

	2: you're doing random I/O into the file and the read fails (any
	I/O to anything smaller than a whole block involves read-update-write).
	(pop quiz: why isn't this a problem when doing sequential writes?)

	solution: wait when doing I/O into a block that's not already in
	memory. Most random I/O tends to be localised into a few places, so
	you'll still see some performance improvement, and at worst it will
	be no slower than it is now.

The final result will be an amazing improvement in speed-of-DOG. Trust me,
or compare speed-of-UNIX to speed-of-MSDOS some time.
-- 
-- Peter da Silva `-_-' ...!seismo!soma!uhnix1!sugar!peter
--                 'U`  <-- Public domain wolf.