Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!usc!julius.cs.uiuc.edu!ux1.cso.uiuc.edu!news.cs.indiana.edu!maytag!xenitec!tirith!ggk From: ggk@tirith.UUCP (Gregory Kritsch) Newsgroups: comp.sys.amiga.tech Subject: Re: Re: PIPEing from ser: Message-ID: Date: 24 Nov 90 01:32:29 GMT References: <11640025@hpfcdc.HP.COM> <1990Nov16.104712.20944@phoenix.pub.uu.oz.au> Lines: 31 In-Reply-To: koren@hpfcdc.HP.COM (Steve Koren) koren@hpfcdc.HP.COM (Steve Koren) writes: >> floppy with a few hundred small files in it. Watch the terminal program >> lose characters. Watch jrcomm die. The terminal program can only hold to >> a certain point, then buffers start to overrun. >Try using flow control. CTS/RTS will allow most terminal programs to >stop the sender while they digest the recently sent data. The whole point of the discussion is quite simple: a call to Write() will take as long as it pleases to take. If you happen to be a terminal program, and it takes 10 hours for the user to wake up the next morning and stick the right disk in, chances are the other end of session has timed out on you. Also, the calls are generally syncronous, so the terminal program can't do anything while waiting for the Write() to return. There are ways using asyncronous io and large allowable memory buffer sizes to safely download a file to a disk not currently in any drive. Essentially, whenever you queue one write request, you allocate another buffer if none have returned. If you have the RAM, the transfer will complete normally with a number of queued write requests, which will get processed when the disk is mounted. > - steve -- Gregory Kritsch | University of Waterloo Fido: 1:221/208.11110 [1:163/109.30] | 1A Computer Engineering OCUG: ggk@tirith.ocug.on.ca |---------------------------- UUCP: ggk@tirith.UUCP | The University doesn't get ...!watmath!xenitec!tirith!ggk | a chance to censor me!