jafischer@watrose.UUCP (01/29/87)
About that message I posted awhile ago questioning multitasking's real worth: Interesting... up till now, I guess I simply hadn't been exposed to true multitasking. CMS, TSO, and all the others I've used on various work terms are more like single task systems with background processing. My limited experience gives me no knowledge of how to switch between foreground tasks on those systems. And up until a few kind Net-ers revealed to me the wonders of ^Z in Unix, Unix was the same thing. (Is this ^Z thingy fairly obvious in the Unix manuals? I read the csh 'man' entry, and I don't remember any reference to it. Nor in the dozens & dozens of other manual entries I've perused...) The point is, it's not just multitasking, but the ability to jump between various tasks, that's so valuable. I see that now. Of course, _you_ all know that, you Amiga guys you. Now, my original question _was_ rather naive and simple-minded, but I was running on about 2 hours' sleep, and besides, if it wasn't for that message, I never would have learned about this wondrous task-switching secret of Unix (at least, Unix 4.2BSD, I'm informed). I wonder if Beckemeyer's MT C-Shell for the ST has this ^Z capability... -- - Jonathan Fischer (jafischer@watrose) or: watmath!watrose!jafischer or: jafischer%watrose@waterloo.csnet or: jafischer%watrose@waterloo.csnet@csnet-relay.arpa
smaug@eneevax.UUCP (Kurt J. Lidl) (07/28/88)
In article <1209@flatline.UUCP> erict@flatline.UUCP (j eric townsend) writes: >In article <4322@cbmvax.UUCP>, marc@cbmvax.UUCP (Marc Rifkin CATS) writes: >> Just be glad ... >> You have the only computer that REALLY ^^^^^^^^ [I'm going to assume he meant "microcomputer"] >> multitasks. >Is this: >a. a jab at OS/2, or >b. a dogmatic statement that doesn't take into account the unix-pc or >'86 based unix systems? or c. a mondo-jab at "MacMultitasking" d. a proud reference to a PC OS that had the "vision" to include multiple tasks, virtual machines and all that other good multi-tasking lingo from the BEGINNING, instead of the "Gee - that is useful, lets put it in the next update to the OS!" mentality I personally vote for option d. (Obscure movie reference: What was the one in the middle?) >Just curious, not flaming you. Me too... >[stuff about OS9 sent to the bit-bucket for resource reclaimation :-)] >J. Eric Townsend Kurt Lidl -- ================================================================== == Kurt J. Lidl (smaug@eneevax.umd.edu) (301)454-6849 == == UUCP: [seismo,allegra]!umcp-cs!eneevax!smaug == ========"It's after 3am, no point in going to sleep now..."=======
dmg@ssc-vax.UUCP (David Geary) (09/28/88)
In some article somewhere, someone writes: > >>Maybe, maybe not. OS/9 has been around for a long time on coco's, Atari's, >>pc's etc. Anyway well a lot of people always talk about multitasking, I >>just don't think it is such a killer feature. Just look at all the Apple, >>IBM sales. It seems that most people are willing to live without multitasking >>or settle for a limited form of multitasking. So while multitasking is a >>definite plus, I doult if it is the reason for people to buy the Amiga over >>something else. Well, it was the ONLY reason I chose the Amiga over the Atari ST. I debated about which one to buy (I have friends who have both machines), but multitasking was the feature that sold me. Then Dave Scroggins writes: >This is true ONLY if they have not used multitasking machines to any >extent. (in MY opinion) I find that when I have to go to a non multitasking, >or multitasking windowless system things are painfully more tedious to do. >I'm not sure which I like better about the AMIGA -- the graphics or the >multitasking. I am teaching C on a Vax here at work, and I know *nothing* about VMS. I don't know how or *if* it's possible to start up another process in VMS. (nor do I care ;-) I have about 12 students, and about 25 terminals. After one class of painful waiting for the linker on the Vax, many of my students have learned a neat trick: Compile and link on one terminal (about a 3 minute process - yes about as slow as compiling C on an Amiga off floppies), and then move over to another terminal and log into it, and use the editor while the linker does it's work. Think my students would appreciate multitasking? -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~ David Geary, Boeing Aerospace, ~ ~ #define Seattle RAIN ~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
rsine@nswc-wo.arpa (09/28/88)
I know I really shouldn't be writing this here, but I can't let something this blatant go by and perhaps give other net users the wrong idea. Get ready to be blasted David. In message-Id: <2259@ssc-vax.UUCP> David Geary writes: > I am teaching C on a Vax here at work, and I know *nothing* > about VMS. I don't know how or *if* it's possible to start up > another process in VMS. First of all it is possible. Secondly, there's many ways to do it. The easiest of which is by using the Spawn command. I would strongly suggest you read the DCL dictionary. If you don't read the whole book at least look up the Spawn command. If you're teaching programming on a VAX/VMS system the people ought to be able to write their own program to execute the compile/link as a seperate process while they are editing. I suggest you give the RTL book a looking over. Then graduate to system services, please. I don't write Fortran code I write VMS Fortran code. Get the distinction? >(nor do I care ;-) You certainly should care and I don't think it's funny. Read on. > I have about 12 students, and about 25 terminals. After one > class of painful waiting for the linker on the Vax, many of my > students have learned a neat trick: > Compile and link on one terminal (about a 3 minute process - yes > about as slow as compiling C on an Amiga off floppies), and then > move over to another terminal and log into it, and use the > editor while the linker does it's work. That "trick" is probably helping to cause the compiles/links to take so long. One of the worst thangs you can do to degradate the performance of a VAX/VMS system is to have a bunch of logins taking place. If my VAX/VMS system compiled programs as slowly as my Amiga using floppies I'd be tuning my system. > Think my students would appreciate multitasking? They are already using one of the most powerful multitasking/multiprocess/ multiuser operating systems known to mankind. You must be kidding, to compare the AmigaDos operating system to the robust VMS operating system is a futile practice of obsurdity. > Well, it was the ONLY reason I chose the Amiga over the Atari > ST. I debated about which one to buy (I have friends who have > both machines), but multitasking was the feature that sold me. That's the exact reason I bought the Amiga over the ST, I wanted multitasking like I have at work (i.e. VMS). If all of your comments were a joke please excuse me I thought you were serious. If you wish to discuss this further (or seek assistance) I am on ArpaNet - rsine@nswc-wo.arpa Ran
BEB%UNO.BITNET@cunyvm.cuny.edu (09/29/88)
> I am teaching C on a Vax here at work, and I know *nothing* > about VMS. I don't know how or *if* it's possible to start up > another process in VMS. (nor do I care ;-) Rather strange attitude from an instructor who has to deal with VMS? Suppose you had to compile and run homework assignments for each student? > Compile and link on one terminal (about a 3 minute process - yes > about as slow as compiling C on an Amiga off floppies), and then Put your class all on the same Amiga. :) > move over to another terminal and log into it, and use the > editor while the linker does it's work. > Think my students would appreciate multitasking? They do, that's why they're doing it. They're just using more hardware than they need. Type "help spawn" sometime. You'll see they can do it all from one terminal. Multitasking is great, but *windowing* is the icing on the cake. Not only can you do multiple things, but you can *see* them being done. >~ David Geary, Boeing Aerospace, ~ --Bruce P.S. Just had an Apollo demonstrated to me. Wow. Jaw still dragging on floor. Saw nice looking hires picture of a mandrill. Looked familiar... :) death before disclaimer <><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><> <>Handle: Bruce Bettis USnail: University of New Orleans <> <>BITnet: <BEB@UNO.BITNET> Computer Research Center <> <>Voices: (504) 286-7067 New Orleans, La. 70148 <> <><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
daveh@cbmvax.UUCP (Dave Haynie) (10/01/88)
in article <4289@louie.udel.EDU>, rsine@nswc-wo.arpa says: >> I am teaching C on a Vax here at work, and I know *nothing* >> about VMS. I don't know how or *if* it's possible to start up >> another process in VMS. Just for reference, I programmed professionally under VAX/VMS before coming to work at Commodore. > First of all it is possible. Secondly, there's many ways to do it. > The easiest of which is by using the Spawn command. I would strongly > suggest you read the DCL dictionary. If you don't read the whole book > at least look up the Spawn command. There, you've said it yourself. READ THAT MANUAL. VMS certainly offers a nice multitasking environment to a seasoned user, but even UNIX makes it easier. In the Amiga environment, all you need to do is click on the CLI icon again, and you get CLI level multitasking. Under UNIX, you need only to put a "&" at the end of the line in many cases, but when you have to deal with interactive multitasking, forget it. Output can be put in a file. Under VMS, just about everyone I know who's used it extensively has written some kind of DCL script to make it useful. Certainly for me, SPAWN worked, but it wasn't sufficient on it's own. >>... Compile and link on one terminal (about a 3 minute process - yes >> about as slow as compiling C on an Amiga off floppies), and then >> move over to another terminal and log into it, and use the >> editor while the linker does it's work. > That "trick" is probably helping to cause the compiles/links to take > so long. One of the worst thangs you can do to degradate the performance > of a VAX/VMS system is to have a bunch of logins taking place. ... Sure enough. That should IMMEDIATELY point out the problem with VMS multitasking, or UNIX multitasking for that matter. > They are already using one of the most powerful multitasking/multiprocess/ > multiuser operating systems known to mankind. You must be kidding, to > compare the AmigaDos operating system to the robust VMS operating system > is a futile practice of obsurdity. Not necessarily. Certainly comparing VMS on an 8xxx series VAX to a plain old A1000 would be foolish. An A1000 with a good hard disk system will give an 11/750 a run for its money, but anything under VMS is also multiuser, a distinct advantage in the college environment mentioned. VMS is in some ways robust. You get named subprocesses that you can start and stop as you like. But you need to be an experienced user, if not an expert, to really take advantage of all of this. There's also resource tracking, which you don't get on the Amiga. The Amiga's multitasking is superior in some ways. First of all, EXEC uses far less CPU time to manage tasks than either VMS or UNIX. ALL tasks are lightweight tasks, so there's very little penalty for using them. And with the Amiga environment, multitasking is as simple as klicking on an icon. A large portion of the usefulness of any computer can be measured by how easily whatever power available there can be tapped by a user. Accelerated Amigas can also run, for single users, in the speed relm of 780 and 8xxx VAXen. And really, how many VMS programs typically run as many individual tasks? The only one I know of is the Emacs we use, and about all that does is spawn itself and provide commands (again, via a DCL script) to keep itself running in the background and permit the user entry and exit pretty easily. Still, not as easy as A-N/A-M. The main problem with the Amiga's multitasking is lack of memory protection or resource tracking. Which amounts to the fact that an errant task can easily crask the machine, and that tasks can only be stopped under use control if the user has direct control of that task (as in interactive tasks) or if that task chooses to listen to the OS stop signals. Because the OS doesn't track resources, each program must, and that makes stop signals necessarily optional. > Ranb -- Dave Haynie "The 32 Bit Guy" Commodore-Amiga "The Crew That Never Rests" {ihnp4|uunet|rutgers}!cbmvax!daveh PLINK: D-DAVE H BIX: hazy "I can't relax, 'cause I'm a Boinger!"
daveh%cbmvax.uucp@UDEL.EDU (10/04/88)
Received: from CUNYVM by CUNYVM.BITNET (Mailer X2.00) with BSMTP id 5755; Fri, 30 Sep 88 21:19:54 EDT Received: from UDEL.EDU by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with TCP; Fri, 30 Sep 88 21:19:50 EDT Received: from Louie.UDEL.EDU by Louie.UDEL.EDU id ad17280; 30 Sep 88 20:37 EDT Received: by Louie.UDEL.EDU id ad17131; 30 Sep 88 20:25 EDT Received: from USENET by Louie.UDEL.EDU id aa16718; 30 Sep 88 20:10 EDT From: Dave Haynie <daveh@cbmvax.uucp> Subject: Re: Multitasking Message-ID: <4906@cbmvax.UUCP> Date: 30 Sep 88 19:37:58 GMT Organization: Commodore Technology, West Chester, PA To: amiga-relay@UDEL.EDU Sender: amiga-relay-request@UDEL.EDU in article <4289@louie.udel.EDU>, rsine@nswc-wo.arpa says: >> I am teaching C on a Vax here at work, and I know *nothing* >> about VMS. I don't know how or *if* it's possible to start up >> another process in VMS. Just for reference, I programmed professionally under VAX/VMS before coming to work at Commodore. > First of all it is possible. Secondly, there's many ways to do it. > The easiest of which is by using the Spawn command. I would strongly > suggest you read the DCL dictionary. If you don't read the whole book > at least look up the Spawn command. There, you've said it yourself. READ THAT MANUAL. VMS certainly offers a nice multitasking environment to a seasoned user, but even UNIX makes it easier. In the Amiga environment, all you need to do is click on the CLI icon again, and you get CLI level multitasking. Under UNIX, you need only to put a "&" at the end of the line in many cases, but when you have to deal with interactive multitasking, forget it. Output can be put in a file. Under VMS, just about everyone I know who's used it extensively has written some kind of DCL script to make it useful. Certainly for me, SPAWN worked, but it wasn't sufficient on it's own. >>... Compile and link on one terminal (about a 3 minute process - yes >> about as slow as compiling C on an Amiga off floppies), and then >> move over to another terminal and log into it, and use the >> editor while the linker does it's work. > That "trick" is probably helping to cause the compiles/links to take > so long. One of the worst thangs you can do to degradate the performance > of a VAX/VMS system is to have a bunch of logins taking place. ... Sure enough. That should IMMEDIATELY point out the problem with VMS multitasking, or UNIX multitasking for that matter. > They are already using one of the most powerful multitasking/multiprocess/ > multiuser operating systems known to mankind. You must be kidding, to > compare the AmigaDos operating system to the robust VMS operating system > is a futile practice of obsurdity. Not necessarily. Certainly comparing VMS on an 8xxx series VAX to a plain old A1000 would be foolish. An A1000 with a good hard disk system will give an 11/750 a run for its money, but anything under VMS is also multiuser, a distinct advantage in the college environment mentioned. VMS is in some ways robust. You get named subprocesses that you can start and stop as you like. But you need to be an experienced user, if not an expert, to really take advantage of all of this. There's also resource tracking, which you don't get on the Amiga.
daveh%cbmvax.uucp%UDEL.EDU@cunyvm.cuny.edu (10/04/88)
Received: from CUNYVM by CUNYVM.BITNET (Mailer X2.00) with BSMTP id 5629; Mon, 03 Oct 88 21:26:29 EDT Received: from UDEL.EDU by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with TCP; Mon, 03 Oct 88 21:26:26 EDT Received: from Louie.UDEL.EDU by Louie.UDEL.EDU id aj10567; 3 Oct 88 18:11 EDT Received: from USENET by Louie.UDEL.EDU id aa10312; 3 Oct 88 17:59 EDT From: daveh%cbmvax.uucp@UDEL.EDU Subject: Re: Multitasking Message-ID: <4391@louie.udel.EDU> Date: 3 Oct 88 21:59:27 GMT To: amiga-relay@UDEL.EDU Sender: amiga-relay-request@UDEL.EDU Received: from CUNYVM by CUNYVM.BITNET (Mailer X2.00) with BSMTP id 5755; Fri, 30 Sep 88 21:19:54 EDT Received: from UDEL.EDU by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with TCP; Fri, 30 Sep 88 21:19:50 EDT Received: from Louie.UDEL.EDU by Louie.UDEL.EDU id ad17280; 30 Sep 88 20:37 EDT Received: by Louie.UDEL.EDU id ad17131; 30 Sep 88 20:25 EDT Received: from USENET by Louie.UDEL.EDU id aa16718; 30 Sep 88 20:10 EDT From: Dave Haynie <daveh@cbmvax.uucp> Subject: Re: Multitasking Message-ID: <4906@cbmvax.UUCP> Date: 30 Sep 88 19:37:58 GMT Organization: Commodore Technology, West Chester, PA To: amiga-relay@UDEL.EDU Sender: amiga-relay-request@UDEL.EDU in article <4289@louie.udel.EDU>, rsine@nswc-wo.arpa says: >> I am teaching C on a Vax here at work, and I know *nothing* >> about VMS. I don't know how or *if* it's possible to start up >> another process in VMS. Just for reference, I programmed professionally under VAX/VMS before coming to work at Commodore. > First of all it is possible. Secondly, there's many ways to do it. > The easiest of which is by using the Spawn command. I would strongly > suggest you read the DCL dictionary. If you don't read the whole book > at least look up the Spawn command. There, you've said it yourself. READ THAT MANUAL. VMS certainly offers a nice multitasking environment to a seasoned user, but even UNIX makes it easier. In the Amiga environment, all you need to do is click on the CLI icon again, and you get CLI level multitasking. Under UNIX, you need only to put a "&" at the end of the line in many cases, but when you have to deal with interactive multitasking, forget it. Output can be put in a file. Under VMS, just about everyone I know who's used it extensively has written some kind of DCL script to make it useful. Certainly for me, SPAWN worked, but it wasn't sufficient on it's own. >>... Compile and link on one terminal (about a 3 minute process - yes >> about as slow as compiling C on an Amiga off floppies), and then >> move over to another terminal and log into it, and use the >> editor while the linker does it's work. > That "trick" is probably helping to cause the compiles/links to take > so long. One of the worst thangs you can do to degradate the performance > of a VAX/VMS system is to have a bunch of logins taking place. ... Sure enough. That should IMMEDIATELY point out the problem with VMS multitasking, or UNIX multitasking for that matter. > They are already using one of the most powerful multitasking/multiprocess/ > multiuser operating systems known to mankind. You must be kidding, to > compare the AmigaDos operating system to the robust VMS operating system > is a futile practice of obsurdity. Not necessarily. Certainly comparing VMS on an 8xxx series VAX to a plain old A1000 would be foolish. An A1000 with a good hard disk system will give an 11/750 a run for its money, but anything under VMS is also multiuser, a distinct advantage in the college environment mentioned. VMS is in some ways robust. You get named subprocesses that you can start and stop as you like. But you need to be an experienced user, if not an expert, to really take advantage of all of this. There's also resource tracking, which you don't get on the Amiga.
daveh%cbmvax.uucp%UDEL.EDU%cunyvm.cuny.edu@cunyvm.cuny.edu (10/04/88)
Received: from CUNYVM by CUNYVM.BITNET (Mailer X2.00) with BSMTP id 6350; Mon, 03 Oct 88 23:04:37 EDT Received: from UDEL.EDU by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with TCP; Mon, 03 Oct 88 23:04:34 EDT Received: from Louie.UDEL.EDU by Louie.UDEL.EDU id aa15979; 3 Oct 88 21:38 EDT Received: from USENET by Louie.UDEL.EDU id aa15900; 3 Oct 88 21:34 EDT From: daveh%cbmvax.uucp%UDEL.EDU@cunyvm.cuny.edu Subject: Re: Multitasking Message-ID: <4482@louie.udel.EDU> Date: 4 Oct 88 01:34:31 GMT To: amiga-relay@UDEL.EDU Sender: amiga-relay-request@UDEL.EDU Received: from CUNYVM by CUNYVM.BITNET (Mailer X2.00) with BSMTP id 5629; Mon, 03 Oct 88 21:26:29 EDT Received: from UDEL.EDU by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with TCP; Mon, 03 Oct 88 21:26:26 EDT Received: from Louie.UDEL.EDU by Louie.UDEL.EDU id aj10567; 3 Oct 88 18:11 EDT Received: from USENET by Louie.UDEL.EDU id aa10312; 3 Oct 88 17:59 EDT From: daveh%cbmvax.uucp@UDEL.EDU Subject: Re: Multitasking Message-ID: <4391@louie.udel.EDU> Date: 3 Oct 88 21:59:27 GMT To: amiga-relay@UDEL.EDU Sender: amiga-relay-request@UDEL.EDU Received: from CUNYVM by CUNYVM.BITNET (Mailer X2.00) with BSMTP id 5755; Fri, 30 Sep 88 21:19:54 EDT Received: from UDEL.EDU by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with TCP; Fri, 30 Sep 88 21:19:50 EDT Received: from Louie.UDEL.EDU by Louie.UDEL.EDU id ad17280; 30 Sep 88 20:37 EDT Received: by Louie.UDEL.EDU id ad17131; 30 Sep 88 20:25 EDT Received: from USENET by Louie.UDEL.EDU id aa16718; 30 Sep 88 20:10 EDT From: Dave Haynie <daveh@cbmvax.uucp> Subject: Re: Multitasking Message-ID: <4906@cbmvax.UUCP> Date: 30 Sep 88 19:37:58 GMT Organization: Commodore Technology, West Chester, PA To: amiga-relay@UDEL.EDU Sender: amiga-relay-request@UDEL.EDU in article <4289@louie.udel.EDU>, rsine@nswc-wo.arpa says: >> I am teaching C on a Vax here at work, and I know *nothing* >> about VMS. I don't know how or *if* it's possible to start up >> another process in VMS. Just for reference, I programmed professionally under VAX/VMS before coming to work at Commodore. > First of all it is possible. Secondly, there's many ways to do it. > The easiest of which is by using the Spawn command. I would strongly > suggest you read the DCL dictionary. If you don't read the whole book > at least look up the Spawn command. There, you've said it yourself. READ THAT MANUAL. VMS certainly offers a nice multitasking environment to a seasoned user, but even UNIX makes it easier. In the Amiga environment, all you need to do is click on the CLI icon again, and you get CLI level multitasking. Under UNIX, you need only to put a "&" at the end of the line in many cases, but when you have to deal with interactive multitasking, forget it. Output can be put in a file. Under VMS, just about everyone I know who's used it extensively has written some kind of DCL script to make it useful. Certainly for me, SPAWN worked, but it wasn't sufficient on it's own. >>... Compile and link on one terminal (about a 3 minute process - yes >> about as slow as compiling C on an Amiga off floppies), and then >> move over to another terminal and log into it, and use the >> editor while the linker does it's work. > That "trick" is probably helping to cause the compiles/links to take > so long. One of the worst thangs you can do to degradate the performance > of a VAX/VMS system is to have a bunch of logins taking place. ... Sure enough. That should IMMEDIATELY point out the problem with VMS multitasking, or UNIX multitasking for that matter. > They are already using one of the most powerful multitasking/multiprocess/ > multiuser operating systems known to mankind. You must be kidding, to > compare the AmigaDos operating system to the robust VMS operating system > is a futile practice of obsurdity. Not necessarily. Certainly comparing VMS on an 8xxx series VAX to a plain old A1000 would be foolish. An A1000 with a good hard disk system will give an 11/750 a run for its money, but anything under VMS is also multiuser, a distinct advantage in the college environment mentioned. VMS is in some ways robust. You get named subprocesses that you can start and stop as you like. But you need to be an experienced user, if not an expert, to really take advantage of all of this. There's also resource tracking, which you don't get on the Amiga.
johnsen@daimi.UUCP (Henrik Johnsen) (10/11/88)
Can anyone give me a discription of the IFF format ANIM? Many Thanks Henrik Johnsen Aarhus, Denmark
armhold@topaz.rutgers.edu (George Armhold) (02/11/89)
I just had a long argument with an IBM owner about multitasking.
I happened to remark that while I was talking to him via the ntalk
command on UNIX, I was composing a .signature file with on my Amiga.
He went into all sorts of long discussion about how the Amiga (and all
other computers) only mimic multitasking, because they are not
re-entrant (a term I do not understand.) He said "wow, I can do the
same thing on my PC." (referring to using a term package and a word
processor at the same time.) I told him that the Amiga can have
several tasks running simultaneously, and ALL tasks are ACTIVE, not
just a dead window. I don't mean to cause all sorts of flames or
computer bashing, but I would like someone to explain to me the
various differences between "true" multitasking and what the Amiga
does (if in deed there is a difference). Comparisons to the IBM PC,
Mac, ST, or any other micros are encouraged. Perhaps you would do
better to E-mail me so as not to cause alot of un-needed bashing on
this great net. I'd hate to be the originator of another "my computer
is better than yours!" war. Thanks in advance and again, please
surpress your flames...
-GEAarmhold@topaz.rutgers.edu (George Armhold) (02/11/89)
Thanks to everyone who e-mailed me concerning the superiority of Amiga
multitasking over that of the IBM. I threw alot of info at
this guy but frankly, he didn't wanna hear it. (What's that, did I
hear someone whisper "typical IBM user" under their breath?? :-)
Anyway, I try not to argue with someone who's had alot more experience
than myself in a particular subject area- I tend to lose. Thanks
again...
-GEA
--
------------------------------------------------------------------------------
Save a bunny- stop the Draize. |armhold@topaz.rutgers.edu
|
"We saw the wrong and the right. We were for life |Careful with that axe,
and we would never concede it." |Eugene...
-T. Scholz |
-------------------------------------------------------------------------------Sullivan@cup.portal.com (sullivan - segall) (02/14/89)
> > I just had a long argument with an IBM owner about multitasking. >I happened to remark that while I was talking to him via the ntalk >command on UNIX, I was composing a .signature file with on my Amiga. >He went into all sorts of long discussion about how the Amiga (and all >other computers) only mimic multitasking, because they are not >re-entrant (a term I do not understand.) He said "wow, I can do the Reentrant refers to the ability of a piece of code to support more than one program at a time, or in a row. Reentrant code must allocate all of its state data dynamically in order to support any number of processes, and must use no self-modifying code in order to be internally consistent for any process to take control at any time. Almost all of the new 1.3 commands are truly reentrant. To use them in a reentrant fashion you can make them resident. The Amiga libraries have always been reentrant. As many processes can be using the libraries at once as the multitasking kernel can support. >same thing on my PC." (referring to using a term package and a word >processor at the same time.) I told him that the Amiga can have >several tasks running simultaneously, and ALL tasks are ACTIVE, not >just a dead window. I don't mean to cause all sorts of flames or >computer bashing, but I would like someone to explain to me the >various differences between "true" multitasking and what the Amiga >does (if in deed there is a difference). Comparisons to the IBM PC, >Mac, ST, or any other micros are encouraged. Perhaps you would do One of the reasons that many software companies are having trouble porting to the Amiga is that it isn't tolerant of many of the abuses that are common on the PC's. If your task allocates memory, and doesn't ever free it, it will be automatically returned to the system when the program terminates. This is easily done on the PC, which only runs one task at a time (TSR's have more strict rules.) The Amiga doesn't support resource tracking by the operating system. This was a design decision which grew out of the basic premise that the Amiga was a microcomputer. If your task crashes, or doesn't release resources, it isn't as though you'll lose 20 users, and have to fsck for the rest of the day. The last couple of files open may be corrupt, but the filesystem is checked automatically when you reboot, and no doubt the designers imagined that most of the programs running on the machine would be well behaved. If so many programmer hadn't grown used to having all of their resources released for them, they might well be well behaved. The only other weakness of the Amiga OS is that it doesn't have any provisions for multiprocessing. I don't think it will be very long before multiprocessing systems start invading the home computer market. (Anyone is welcome to tell me that I'm dead wrong at this point. (About the OS that is, not about multiprocessing.)) > -GEA -Sullivan Segall ----------------------------------------------------------------------- BSCS Vanderbilt Univ. 1987. Just to prove that I can BS with the best. ----------------------------------------------------------------------- Mail all greivances to: Sullivan@cup.portal.com
DAVEA%CERNVM.BITNET@cunyvm.cuny.edu (David Almond) (08/11/89)
======================================================================== 39 Can't live without it. Yesterday, I was using Kermit to transfer a file from a Macintosh to our VAX. When the transfer finished, I wanted to compare the file sizes of the Mac and VAX versions. I couldn't do it without exiting Kermit, finding the Mac file's icon, and doing an INFO!! I was dying to push the Kermit window "to the back" and do a "dir". An expert Mac user next to me said, "Well, you could do it if you had programs X, Y, and Z installed as desk-accessories." Sigh. >>>>>> Dan >>>>> You must be doing something wrong. I just clicked on the folder I had transfered my mail to and did an info
matt@sapphire.jpl.nasa.gov (matt of ASTD) (06/13/90)
`(1) How does the Amiga truely multitask. Does it have more than one `processor or does there have to be more than one processor in order to `multitask? I heard one person say that there was no true multitasking `because there was only on processor. Note that there is a big difference between multitasking and multiprocessing. Multitasking can be done on a single chip. Most computers today are not considered multiprocessors. However, they do multitask. If you want to understand the difference read a book on operating systems. The amiga does perform true multitasking. So that "one person" has no idea what they are talking about. Some multiprocessing machines are BBN Butterfly, Hypercube, Connection Machine, Transputers, and many others. I know of no PC that is a multiprocessing machine (unless you hook it up to a transputer board). ---------------------------------------------------------------------- Matthew Presley (UCLA CS Grad. Student) & (JPL CS dude) Internet (presley@cs.ucla.edu) or (matt@sapphire.jpl.nasa.gov) "Twisted yellow puppies play broken flutes loudly..."
don@vax1.acs.udel.EDU (Donald R Lloyd) (06/13/90)
In article <4019@jato.Jpl.Nasa.Gov> matt@sapphire.Jpl.Nasa.Gov (matt of ASTD) writes: >Some multiprocessing machines are BBN Butterfly, Hypercube, Connection >Machine, Transputers, and many others. I know of no PC that is a >multiprocessing machine (unless you hook it up to a transputer board). Compaq's SystemPro has 2 386's in it. However, this being an Amiga newsgroup, I won't mention it :-) -- Gibberish .sig for sale or lease. is spoken Contact don@vax1.acs.udel.edu for more information. here. DISCLAIMER: It's all YOUR fault.
arc@desire.wright.edu (12/13/90)
In article <9012130059.AA08767@ucbvax.Berkeley.EDU>, i0046145@WATER.FIT.QUT.EDU.AU (Lukacz Alex) writes: > I've been having major problems with multitasking lately, anyone care to tell > me what exactly is happening or a fix? > > 1) When using DiskMaster (V1.4) and NComm (V1.9) I often copy files or unarc > just-downloaded files while online. Trouble is, when I try to get a > directory (through the 1.3 'List' or 'Dir' commands) whilst unarcing is > taking place, the disk drive managed to 'crunch, crunch' back and forth > for MINUTES. > > I think what is happening here is that the dir command is trying to get to the > tracks around 880 for the list of files whilst the arcing program is still > trying to unarc the program which would be spread over the tracks of the disk. > > Now I think this is rather silly. Surely one task should take priority over > the other, so the 'dir' could intercept the unarcing and get the list of files > and then let arc get back to work. > > I have tried changing the task priority of 'dir' and 'list' but it doesn't seem > to have much (read: any) effect. > > 2) When online a BBS or the VAX/UNIX, the text output to my monitor slows > down IMMENSELY if I'm doing disk-accesses at the same time. For example, > I'm looking for a particular file which I wish to upload. I am certain > it is on one of two disks sitting in my disk-mailer. I wish to get a > directory of both disks so I can find out which one the file is on. I > change windows to the CLI window and then issue 'dir'. Click back to the > NComm window and SHAZAAM! - text output is slowed to an annoyingly slow > rate. This happens both at 2400 and 9600 baud. > > I have absolutely no idea of what is going on here. > > > Any hints/solutions (no flames, send 'em to /dev/null) would be appreciated. > > Alex. Okay, to answer your statements... Your drives EACH have 2 tasks each to "drive" them... Just because we have a processor for some disk accessing, doesn't mean that you won't have a slow down. When writing/reading from a disk drive, each drive has it's own "buffer", and programs have no real priorities to access these. I think someone could explain this better, and also I think you oughta get more info before you post such a message on here, like a book, maybe?
pl@news.funet.fi.tut.fi (Lehtinen Pertti) (12/13/90)
From article <9012130059.AA08767@ucbvax.Berkeley.EDU>, by i0046145@WATER.FIT.QUT.EDU.AU (Lukacz Alex): > I've been having major problems with multitasking lately, anyone care to tell > me what exactly is happening or a fix? > > 1) When using DiskMaster (V1.4) and NComm (V1.9) I often copy files or unarc > just-downloaded files while online. Trouble is, when I try to get a > directory (through the 1.3 'List' or 'Dir' commands) whilst unarcing is > taking place, the disk drive managed to 'crunch, crunch' back and forth > for MINUTES. > > I think what is happening here is that the dir command is trying to get to the > tracks around 880 for the list of files whilst the arcing program is still > trying to unarc the program which would be spread over the tracks of the disk. > > Now I think this is rather silly. Surely one task should take priority over > the other, so the 'dir' could intercept the unarcing and get the list of files > and then let arc get back to work. > > I have tried changing the task priority of 'dir' and 'list' but it doesn't seem > to have much (read: any) effect. > I think your thougth is correct, driver get requests from programs alternating and so between every access there is long seek. While task waits for request to be filled, it is suspended and during dma read other (lower priority) task is switched in. So priorities don't play much role here, because both tasks get time anyway. Adding disk buffers could have more effect, but usually fileheader blocks are spread all over disk, so caching doesn't help much. > 2) When online a BBS or the VAX/UNIX, the text output to my monitor slows > down IMMENSELY if I'm doing disk-accesses at the same time. For example, > I'm looking for a particular file which I wish to upload. I am certain > it is on one of two disks sitting in my disk-mailer. I wish to get a > directory of both disks so I can find out which one the file is on. I > change windows to the CLI window and then issue 'dir'. Click back to the > NComm window and SHAZAAM! - text output is slowed to an annoyingly slow > rate. This happens both at 2400 and 9600 baud. > > I have absolutely no idea of what is going on here. > One reason could be interrupt blocking during certain disk accesses. This prevents serial driver from getting characters at 'usual' rate. > > Any hints/solutions (no flames, send 'em to /dev/null) would be appreciated. > > Alex. pl@tut.fi ! All opinions expressed above are Pertti Lehtinen ! purely offending and in subject Tampere University of Technology ! to change without any further Software Systems Laboratory ! notice
i0046145@WATER.FIT.QUT.EDU.AU (Lukacz Alex) (12/14/90)
I've been having major problems with multitasking lately, anyone care to tell
me what exactly is happening or a fix?
1) When using DiskMaster (V1.4) and NComm (V1.9) I often copy files or unarc
just-downloaded files while online. Trouble is, when I try to get a
directory (through the 1.3 'List' or 'Dir' commands) whilst unarcing is
taking place, the disk drive managed to 'crunch, crunch' back and forth
for MINUTES.
I think what is happening here is that the dir command is trying to get to the
tracks around 880 for the list of files whilst the arcing program is still
trying to unarc the program which would be spread over the tracks of the disk.
Now I think this is rather silly. Surely one task should take priority over
the other, so the 'dir' could intercept the unarcing and get the list of files
and then let arc get back to work.
I have tried changing the task priority of 'dir' and 'list' but it doesn't seem
to have much (read: any) effect.
2) When online a BBS or the VAX/UNIX, the text output to my monitor slows
down IMMENSELY if I'm doing disk-accesses at the same time. For example,
I'm looking for a particular file which I wish to upload. I am certain
it is on one of two disks sitting in my disk-mailer. I wish to get a
directory of both disks so I can find out which one the file is on. I
change windows to the CLI window and then issue 'dir'. Click back to the
NComm window and SHAZAAM! - text output is slowed to an annoyingly slow
rate. This happens both at 2400 and 9600 baud.
I have absolutely no idea of what is going on here.
Any hints/solutions (no flames, send 'em to /dev/null) would be appreciated.
Alex.xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) (12/15/90)
i0046145@WATER.FIT.QUT.EDU.AU (Lukacz Alex) writes: > I've been having major problems with multitasking lately, anyone care > to tell me what exactly is happening or a fix? > 1) When using DiskMaster (V1.4) and NComm (V1.9) I often copy files or > unarc just-downloaded files while online. Trouble is, when I try to > get a directory (through the 1.3 'List' or 'Dir' commands) whilst > unarcing is taking place, the disk drive managed to 'crunch, crunch' > back and forth for MINUTES. > I think what is happening here is that the dir command is trying to > get to the tracks around 880 for the list of files whilst the arcing > program is still trying to unarc the program which would be spread > over the tracks of the disk. > Now I think this is rather silly. Surely one task should take priority > over the other, so the 'dir' could intercept the unarcing and get the > list of files and then let arc get back to work. > I have tried changing the task priority of 'dir' and 'list' but it > doesn't seem to have much (read: any) effect. Well, the problem is that the size of the time slice for multitasking is _much_ smaller than the time needed to do do a DIR on a fairly large directory, so what you are hearing looks like this: Start arc .. Start dir .. arc is sleeping waiting for a disk i/o head is moving toward arc's block dir asks for a directory block, gives up control, goes to sleep head continues for arc block arc block is found, read, arc is marked ready to run head starts toward next request, dir's directory block arc is ready to run, arc processes a little, is preempted dir is still waiting for a block arc wakes, processes, is preempted, etc arc has completed a read or ready to write block, asks for disk i/o, sleeps head continues for dir's directory block, reads it, dir is marked ready to run head starts toward next request, arc's block dir is ready to run, processes a dir block, asks for next block, goes to sleep head continues toward arc's block go to top The alternative would be to completely lock out one or the other process until the higher priority process was done. The problem is that, once the head starts toward an i/o block, that process is not (nor should it be) interruptable. The net result is that you are getting blocks alternately for the two running tasks. > 2) When online a BBS or the VAX/UNIX, the text output to my monitor > slows down IMMENSELY if I'm doing disk-accesses at the same time. For > example, I'm looking for a particular file which I wish to upload. I > am certain it is on one of two disks sitting in my disk-mailer. I wish > to get a directory of both disks so I can find out which one the file > is on. I change windows to the CLI window and then issue 'dir'. Click > back to the NComm window and SHAZAAM! - text output is slowed to an > annoyingly slow rate. This happens both at 2400 and 9600 baud. > I have absolutely no idea of what is going on here. OK, when you aren't doing anything at all, but your host site is a bit slow, watch the idiot lights on your modem, and you will notice a perceptible delay between the flicker indicating data passing through your modem, and the characters showing up on your screen. There is a considerable amount of work done to draw the characters. For sure, having the processor busy cuts down the time it has to draw characters on your screen. Beyond that, if the character display is being done with the blitter, then the disk MFM decoding is fighting with the character display over the use of the blitter. Since directory blocks are scattered across floppies, and since reading a single block from an Amiga floppy involves reading and decoding a whole track, every time a directory block is on a new track, the blitter is _very_ busy during a DIR command. >Any hints/solutions (no flames, send 'em to /dev/null) would be appreciated. You have my best guesses; better data takes a better author. /// It's Amiga /// for me: why Kent, the man from xanth. \\\/// settle for <xanthian@Zorch.SF-Bay.ORG> <xanthian@well.sf.ca.us> \XX/ anything less? -- Convener, ongoing comp.sys.amiga grand reorganization.
farren@well.sf.ca.us (Mike Farren) (12/16/90)
i0046145@WATER.FIT.QUT.EDU.AU (Lukacz Alex) writes: >I've been having major problems with multitasking lately, anyone care to tell >me what exactly is happening or a fix? He goes on to describe floppy gronking while trying to do multiple accesses, and slowdown in serial stuff while doing floppy stuff. The disk gronking is, unfortunately, due to the nature of the OS disk access routines. If you have two routines, each accessing different tracks/sectors, the trackdisk routines just shuffle between the two tracks, resulting in a lot of long seeks (gronk!). Nothing you can do about it, I'm afraid, as long as you're running on a pure floppy system. The serial slowdown doesn't have quite so clear a cause, but might well be related to the fact that the serial port and the disk both share one of the PIA chips. Don't know about this one, though. The solution? Don't do multiple floppy accesses, or access the floppy while you're using your serial port. Sounds smart-assed, I know, but... I used to have exactly these problems. These days, I tend not to use floppies directly unless I can't help it. Add some RAM, and do your work in the RAM: disk (or a recoverable ramdrive), and your problem will disappear. Or add a hard drive, and similar good things will result. -- Mike Farren farren@well.sf.ca.us