Re: OS For IIGS

[remco@mat002103.student.utwente.nl (Remco Post)]

In article <markem-2311970007220001@hsh18-57.flash.net>,
	markem@flash.net (Mark Manning) writes:
> Ok, earlier I ranted and raved on here.  I'm feeling much better now but
> I'd like to submit an addendum to what I've already posted.
> 
> Some people will dispute with me that a W'95 machine and a Mac is doing
> Multitasking.  Granted, the generic, broad scope meaning of Multitasking
> is that a computer can perform more than one task at a time (or actually
> to SEEM like it is doing more than one task at a time).  In order to do
> true Multitasking you'd really have to have more than one processor going
> at one time.
> 
> So let's discount the need for a multiprocessor system and just stick to
> the part about can it handle switching between various processes.  Again,
> in the most general sense of the wording - yes.  It can.  Where my pet
> peeve comes into play is that this is not always true of the Mac or W'95
> computers.  And here is why:
> 
> Both the Mac and W'95 computers make their programs be the masters and the
> OS be the slave.  What I mean is: Is that both the Mac and W'95 programs
> have to contain a small bit of code (on the Mac it is a single call
> statement) which returns control of the computer to the system.  If this
> isn't included in the program though, the Mac (and W'95 does this too)
> will simply allow that one program to take over the entire computer.  This
> is not true with Unix based OS's.  Under Unix, the OS is the master and
> the programs are the slaves.  Which is how it should be.  If you want to
> test this out it is very easy.  All you have to do is to create a very
> small program which does nothing but loop.  Like this:
> 
> c:
> 
> main() {  while( 1 ); }
> 
> Basic:
> 
> 5 goto 5
> 
> Fortran:
> 
> 5 goto 5
> 
> (You get the idea.)
> 
> Now, there are a few conditionals to the above.  First, you can not use an
> interpreted language.  This is because the interpreters have the code
> built into them to allow control to pass back to the system.  Second, you
> have to make sure that no additional code which handles calling the system
> is included by accident (Code Warrior I think does this if you have the
> proper options set).
> 
> Compile it.  Run it.  Once you do - you will not be able to get control of
> your computer back.  At least, using Turbo C, PowerBasic, Microsoft C,
> Microsoft Fortran, CodeWarrior, Think C v5.0, and FutureBasic I could
> not.  However, on my Linux box - I could.  It took a while.  I grant you
> that.  It took a while because that program was sucking up CPU usage like
> crazy.  But Linux could still give me back control so I could kill the
> program.
> 
> This (to me) _is_ the test of a true multitasking OS.  And if it can't
> handle it - then the OS isn't really multitasking.  It's timesharing. 
> Which (to me) is different.  That is to say: A true multitasking OS
> multitasks ALL OF THE TIME.  No matter what's going on, no matter who's
> doing what, no matter how many resources are being used; you still can run
> all of your programs on that computer and have all of them doing
> something.
> 
Timesharing is exactly the kind of miltitasking every multitasking OS does.
BUT Unix uses a timer to determine is a context switch is due. MacOS does
this by intercepting at the getnextevent() syscall. Both are defendable.
The unix system has the advantage that under all circumstances it's
possible to switch context. The MacOS scheme has the advantage that the
foreground app (the one I'm talking to) has control over when it will give
up the processor. You could think of this as an disadvantage, but you should
keep in mind that the Mac was build as a single user workstation, and people
generally can do only one thing at a time. Aslo an app cannot get to know
of user actions without calling getnextevent() and thus potentially giveing
up the CPU.

Your example also tells us one other thing. If an app has nothing to do but
wait in a loop, it should be programmed in such a way that the OS know about
this and suspends the app until there is something to do. This is true for
all OS'es, and is why Unix has this kind of info in the schedulers
procesqueue. Apps waiting for something to happen don't get run until that
happens. Your example app is regarded a dirty app on all systems, for
it does consume cpu time while doing nothing. Try this on a 100 user unix
mainframe nad people around you will give you very dirty looks.

> Now granted, a lot of PR work has gone on with the various computer
> companys.  Those marketing guys can make you think an IBM PC XT can do as
> much as a Pentium 500mhz system.  But if the OS isn't always in control of
> what is going on inside of that computer - it doesn't matter what some
> sales person, marketing guy, or PR man is over there yelling at you.  It's
> just not true.  No matter what they say.  No matter how they might want to
> put it.  The system is still not multitasking.
> 
> Ok, now I will return to lurk mode and everyone can bang away at what I've
> said.  Have fun!  :-)

Remco