Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!usc!apple!lsr
From: lsr@Apple.com (Larry Rosenstein)
Newsgroups: comp.sys.amiga.advocacy
Subject: Re: Multitasking.
Message-ID: <11834@goofy.Apple.COM>
Date: 24 Jan 91 03:16:48 GMT
References: <1991Jan21.032207.6127@cunixf.cc.columbia.edu> <4827@skye.cs.ed.ac.uk> <12913@life.ai.mit.edu> <12916@life.ai.mit.edu>
Sender: usenet@Apple.COM
Organization: Apple Computer, Inc.
Lines: 46

In article <12916@life.ai.mit.edu>, rjc@geech.ai.mit.edu (Ray Cromwell) writes:
> 
>   The Mac programmer must decide CAREFULLY where to place I/O calls to 
> give up the CPU. If the compute loop is sufficiently complex( nested),
> he will have to put them in many places.

You definitely have to insert extra calls, but it isn't as hard as you
make it out to be.  There are 2 approaches you can take:

(1) You run performance tools to find out where the program spends most of
its time.

(2) You mechanically insert calls into all the loops of the program, and 
at the beginning and end of each routine.  (The latter can be done
automatically by some of the Mac compilers.)  These calls are to a routine
that yields the CPU every N ticks.

I've used each of these techniques to port vanilla C programs to the Mac
and get them to run in the background.

>   Mac users must consider what Amiga users typically do. An artist may
> place a long ray-trace task at -1 priority in the background and let it
> run for a week! A programmer will put a compile in the background while
> editing or reviewing source.

And Mac users do exactly the same things.  I put compiles in the background
all the time, and I suspect that most if not all rendering programs also
work in the background.

>   I suspect the Mac's lack of priorities and preemptive tasking would cause
> foreground tasks to become jerky if compute intensive tasks are placed in
> the background (such as a long ray-trace).

The foreground task sometimes pauses (primarily during I/O) but mostly
everything runs smoothly.

> software published before Multifinder was invented will be CPU hogs.

This is true of CPU-bound programs.  Programs that are user-input-bound
are not CPU hogs under MultiFinder.

> Consider the Amiga's Task Control Block, or struct Process, can anybody
> tell me what the Mac equivelent is?

These things exists in the internals of MultiFinder, but they up to now they
have not been exported to programmers.  This is changed in System 7.