pes@ux63.bath.ac.uk (Smee) (01/07/88)
Well, that provoked a lot more response than I'd thought it might when I made the original posting. I also got a fair bit of email about it. (I tried to reply to each individually, but a lot of the replies bounced -- if you didn't get yours, thanks for your response anyway. I told the people I got mail from that I would post a summary -- so here goes.) The mail I received (which didn't degenerate into a flame war) seemed to be divided about 50-50 for/against my ORIGINAL proposition. Please NOTE (since it seems to have gotten lost in the discussion) that I didn't say that multi- tasking wasn't NICE or USEFUL -- I said (or at least, thought I said) that I didn't think it could be considered to be the be-all and end-all -- and that for my purposes at least, simpler interrupt handlers were totally sufficient. (And, that on a small, e.g. 500K, machine, I couldn't think of many combinations of things that I use which could co-exist in the memory space.) A few particular points which kept cropping up -- Simultaneity is handy and makes writing particular sorts of programs easier. -- OK, I'll grant that. However, a couple of the examples commonly used were mis-chosen, I think. To pick the most common two -- simultaneous compilation and editing: well, I've been converted to 'make' (I know, I said about a year ago that I couldn't see a use for it on a non-hard-disk system) and I tend to have one major project at a time (at home -- unlike work). Don't like the idea of 'make' using files that I am busy editing simultaneously. Concurrent compilation and debugging -- Hmm. Not me. Not until I can get a home micro with protected memory partitions for each application, and with interprocess communication restricted to well-defined, thru-the-OS, gateways. Don't want my half-debugged program running silently amok and deciding to use as workspace the bit of memory where the compiler is constructing my new object segment. Paranoid? Yes -- more so every year. The only thing I want co-resident with a program I'm debugging is the debugger, thanks very much. However, for well-behaved proggies, and given enough memory space to use them sensibly, I can't argue with this one at all. Interrupt handlers and resident accessories are poor seconds to true multi- tasking. -- Sorry, don't buy that. They perform totally different functions, I think. A proper resident accessory is used (MY OPINION) to break out of a task which requires your full attention, to perform some mini-task which requires attention, prior to going back to it. An interrupt handler is a well-proven, easy to write reliably, way of doing I/O and other things which naturally ask for attention when they need it. I'll grant that if you need more than that, you may need multi-tasking; but if you don't, you don't. As for simultaneous print and plot spooling -- well, doesn't bear thinking about, until one or the other of the machines come up with a version with two parallel ports rather than the one -- or until the Async Transport Service protocol catches on. Just because a 'non-power' (whatever that is) user doesn't need it now, doesn't mean he'll NEVER need it. True. But NEVER is a long time in this context. By the time he does need it (in another year or two) all these, our beloved machines, will be painfully obsolete anyway, and we'll be looking at 4 Gigabyte machines, with 68080 chips (don't look in the parts list, I made that up) with builtin math processors, segmented, demand-paged memory with full protection between competing processes. (Actually, the 020 (or do I mean the 030) is getting pretty close already.) (Or maybe, if Acorn can get their pricing into realistic levels, we'll all be wiped out by the Archimedes and similar RISC-technology machines.) Anyhow, I achieved my goals, which were (a) to gain a feeling for how much M/T is used, and (b, I hope) to stir up some thinking. I'd just as soon see this chain stop now -- but if it doesn't, at least keep in mind that the premise is *not* that M/T isn't useful (he says, typing this in while the mainframe gets on with half dozen compilations for him) but that IT IS ONLY ONE CRITERION TO BE KEPT IN MIND AMONG ALL THE OTHERS. IT IS *NOT* THE ONLY GAME IN TOWN. (Sorry for shouting. Happy New Year to the happy owners of both machines.) :-) (Since I think we've talked it to death, replies by mail to me if you can work out a 'reply' address in the midst of all the current gateway changes. If any *new* insights appear, I'll summarize, otherwise I'll abandon.)
alex@.UUCP (Alex Laney) (01/19/88)
In article <2057@bath63.ux63.bath.ac.uk>, pes@ux63.bath.ac.uk (Smee) writes: > > However, for well-behaved proggies, and given enough memory space to use them > sensibly, I can't argue with this one at all. Based on this line alone, this guy has now come (albeit somewhat kicking and screaming) around to thinking multi-tasking is useful. And you know how those lads from Britain are stubborn :-) :-) So let's consider this last article an apology about dragging down multi-tasking. But at the cost of extremely high net bandwidth! -- Alex Laney alex@xicom.UUCP ...utzoo!dciem!nrcaer!xios!xicom!alex Xicom Technologies, 205-1545 Carling Av., Ottawa, Ontario, Canada We may have written the SNA software you use. The opinions are my own.