peter@sugar.UUCP (Peter da Silva) (08/18/87)
Why doesn't AmigaDOS support transparent asynchronous writes? If you're writing a small buffer to an I/O device, you shouldn't have to wait for that I/O device to physically do the I/O. For instance, when you write (for example) a short debugging message to a CON: device, and that window has it's layers locked (say, you hit the spacebar), why should you have to wait for that to go through? AmigaDOS should just verify that the I/O is possible and buffer it up. Same thing with the printer and disk (I know the disk does this... but it does it at a lower level). How about it, C=Amiga? V1.3. -- -- Peter da Silva `-_-' ...!seismo!soma!uhnix1!sugar!peter (I said, NO PHOTOS!)
cc1@CS.UCLA.EDU (08/27/87)
In article <514@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes: >Why doesn't AmigaDOS support transparent asynchronous writes? If you're >example) a short debugging message to a CON: device, and that window has it's >layers locked (say, you hit the spacebar), why should you have to wait for Please, make it an option, preferably switchable. Being able to stop a program by hitting space is a great feature right now. Besides, how do you ever handle I/O errors when you don't know what write caused it? (Even unix has this problem). Michael The opinions represented here are a result of being educated at a school that discriminates againts roosters. Only the birds are responsible.
paulz@hpspdla.HP.COM (Paul Zander) (08/28/87)
Having once used a computer which buffers all I/O, I can say that it can be a real pain in the a**. The example is still fresh in my mind of how the program had diagnostic writes to isolate where it was crashing. It would send the write to the buffer, then proceed to the fatal error, leaving some of the diagnostics still in the buffer! I would agree that the best situation would be to have the operation selectable by the programmer.
peter@sugar.UUCP (08/29/87)
In article <7887@shemp.UCLA.EDU>, cc1@CS.UCLA.EDU writes: > In article <514@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes: > >Why doesn't AmigaDOS support transparent asynchronous writes? If you're > Please, make it an option, preferably switchable. Being able to stop a program > by hitting space is a great feature right now. But you can only stop programs thaw write to a cooked console device that way. How about a window application that lets you pause any task you like? > Besides, how do you ever handle > I/O errors when you don't know what write caused it? (Even unix has this > problem). Why wouldn't you know what write caused it? -- -- Peter da Silva `-_-' ...!seismo!soma!uhnix1!sugar!peter -- U <--- not a copyrighted cartoon :->
ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) (08/30/87)
In article <4160003@hpspdla.HP.COM> paulz@hpspdla.HP.COM (Paul Zander) writes: >Having once used a computer which buffers all I/O, I can >say that it can be a real pain in the a**. [ ... ] It would send the >write to the buffer, then proceed to the fatal error, leaving >some of the diagnostics still in the buffer! > That is why God invented kprintf(). :-) _-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ Leo L. Schwab -- The Guy in The Cape ihnp4!ptsfa -\ \_ -_ Bike shrunk by popular demand, dual ---> !{well,unicom}!ewhac O----^o But it's still the only way to fly. hplabs / (pronounced "AE-wack") "Work FOR? I don't work FOR anybody! I'm just having fun." -- The Doctor
dillon@CORY.BERKELEY.EDU.UUCP (08/31/87)
>In article <4160003@hpspdla.HP.COM> paulz@hpspdla.HP.COM (Paul Zander) writes: >>Having once used a computer which buffers all I/O, I can >>say that it can be a real pain in the a**. [ ... ] It would send the >>write to the buffer, then proceed to the fatal error, leaving >>some of the diagnostics still in the buffer! >> >Leo L. Schwab: > That is why God invented kprintf(). :-) And why STDERR is always unbuffered (or supposed to be). -Matt
fnf@mcdsun.UUCP (Fred Fish) (08/31/87)
]]]write to the buffer, then proceed to the fatal error, leaving ]]]some of the diagnostics still in the buffer! ]]Leo L. Schwab: ]] That is why God invented kprintf(). :-) ]Matt Dillon: ] And why STDERR is always unbuffered (or supposed to be). Me: And why I always use an fflush after diagnostics no matter what the stream is. :-) -Fred -- = Drug tests; just say *NO*! = Fred Fish Motorola Computer Division, 3013 S 52nd St, Tempe, Az 85282 USA = seismo!noao!mcdsun!fnf (602) 438-3614
kurt@tc.fluke.COM (Kurt Guntheroth) (09/06/87)
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?
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.dillon@CORY.BERKELEY.EDU (Matt Dillon) (09/06/87)
>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? > >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. (1) No. The only difference between asyncronous and syncronous IO is that we do not wait for the message to come back before allowing the caller to resume. Since the caller explicitly wants asyncronous IO, one can assume the request will take a while and that the caller wants to do other things in the mean time. (2) Obviously, you can't know immediately whether the operation failed. The returned error code would be for the previous operation, with the XFCLOSE() call returning the error code for the final operation. BTW: We can only have one pending IO request per file handle anyway or AmigaDOS blows up. I don't understand what people are arguing about. I use asyncronous IO in both DTERM and DME and it works great! -Matt
peter@sugar.UUCP (Peter da Silva) (09/10/87)
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.
peter@sugar.UUCP (Peter da Silva) (09/10/87)
> [Matt dillon noting he's doing asynchronous I/O in DTERM and DME > and it works GREAT] But the subject is transparent asynch I/O. That is, the program doesn't know nor care that the I/O is going on asynchronously. You know, like UNIX does it. Your package looks good, but it doesn't lead to a general improvement in DOS speed. -- -- Peter da Silva `-_-' ...!seismo!soma!uhnix1!sugar!peter -- 'U` <-- Public domain wolf.