Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!husc6!think!ames!ucbcad!ucbvax!decvax!tektronix!tekcrl!tekfdi!videovax!stever From: stever@videovax.Tek.COM (Steven E. Rice, P.E.) Newsgroups: comp.sys.amiga,comp.sys.mac Subject: Re: Mac Multitasking? Hee-hee! Message-ID: <4537@videovax.Tek.COM> Date: Sun, 16-Aug-87 15:02:30 EDT Article-I.D.: videovax.4537 Posted: Sun Aug 16 15:02:30 1987 Date-Received: Wed, 19-Aug-87 03:29:26 EDT References: <6565@eddie.MIT.EDU> <2742@hoptoad.uucp> <3638@cit-vax.Caltech.Edu> <2758@hoptoad.uucp> Reply-To: stever@videovax.Tek.COM (Steven E. Rice, P.E.) Organization: Tektronix Television Systems, Beaverton, Oregon Lines: 86 Summary: "Synchronous multitasking" is a feeble and limited technique. Xref: mnetor comp.sys.amiga:7509 comp.sys.mac:5647 In article <2758@hoptoad.uucp>, Tim Maroney (tim@hoptoad.UUCP) responded to comments by Steve Walton (walton@tybalt.caltech.edu.UUCP), who was in turn responding to an article by Tim. In article <3638@cit-vax.Caltech.Edu>, Steve wrote: >> You mean if I want to do some editing while Mac C Kermit is downloading >> a 150K file for me at 1200 baud, I have to go to another machine? I >> can't type "make" in a CLI window and then go off and play a game? >> Humph... Tim's response began: > Well, as long as the downloading loop cedes control of the processor every > time through, a trivial code change, then synchronous multitasking will > serve this end quite well. I'm not clear on how MultiFinder handles modal > dialogs (the documentation we've been seeded with is rather deficient), but > I believe it will let you change context during them. Anyway, it's pretty > easy to make the download run in the background. The same goes for any > other special-purpose long-lived operation, like Save; but most of what you > do on the Mac doesn't make any sense in the background. That's why I said > that time-slicing is not such a big deal. The important point about time-slicing is that it allows virtually *any* two (or more) programs to multitask WITHOUT requiring even one "trivial code change." Thus, on a system with time-slicing, a Kermit download will co-operate with an editor quite nicely (especially if Kermit is running at a lower priority). The editor will suffer no response degradation, while Kermit will run quickly almost all the time (editors usually spend a lot of time waiting for keystrokes. . .). Another example of such an operation, involving four simultaneously- executing programs interconnected by pipes, was mentioned a while back. In UNIX notation, the operation would be (approximately): % kermit -k | uudecode | uncompress | tar xvf - On the Amiga, pipes are named, so the syntax of the command would be different, but the operation is similar. With the (4K byte) pipe files assigned to RAM:, only the output files are written to floppy. As you can imagine, this provides a dramatic increase in throughput over: % kermit -k archive.tar.Z.uu (writes to floppy) % uudecode archive.tar.Z.uu (reads from and writes to floppy) % uncompress archive.tar.Z (reads from and writes to floppy) % tar xvf archive.tar (reads from and writes to floppy) The time savings from eliminating three enormous writes to disk and three correspondingly enormous reads from disk are tremendous. Also, on small systems, there may not be enough mass storage to hold all the intermediate forms at once. Thus, the user would have to delete intermediate files between steps, or operate from one disk to another (or both!). On my Amiga, which has two floppy disk drives and no hard disk, this would tie up the system completely, as well as requiring my intervention at several places in the process. But with the pipelined version, I would need to use only one disk (for output), so the second drive is freed for other purposes. Further, because of the multitasking, I can still do a compilation in the background *and* edit a file while all this is going on! (This assumes that I have boatloads of memory, of course. . .) With process priorities chosen carefully (e.g., editor priority > download, etc. priority > compilation priority), the editor will be responsive, the download and associated processing will perk right along (limited mainly by the phone line data rate), and the compilation will use up whatever is left of the CPU. This is just one example of enhanced productivity and system utility provided by true multitasking. None of the programs that are running need to know or do anything out of the ordinary in order to multitask. Because it puts the responsibility for task switching on the programs themselves, so-called "synchronous multitasking" only works with programs designed to permit task switching. Compared to true multitasking, "synchronous multitasking" is a feeble and limited technique. Having said all this, I am not about to climb upon my soapbox and proclaim the superiority of the Amiga over the Mac. The ideas that underlie the Amiga operating system come from UNIX and other operating systems. I am confident that, in time, true multitasking will be available on the Mac as well. Steve Rice ----------------------------------------------------------------------------- new: stever@videovax.tv.Tek.com old: {decvax | hplabs | ihnp4 | uw-beaver | cae780}!tektronix!videovax!stever