NetNews Usenet Archive 1992 #18/NN_1992_18.iso/spool/comp/sys/mac/programm/13980

Text File | 1992-08-14 | 3.7 KB | 86 lines

Newsgroups: comp.sys.mac.programmer
Path: sparky!uunet!camex!sunfs3!kent
From: [e-mail] (Kent Borg)
Subject: Re: Creating background tasks (HELP!).
Message-ID: <[e-mail]>
Sender: [e-mail]
Organization: Camex Inc., Boston MA
References: <[e-mail]>
Date: Thu, 13 Aug 1992 20:05:35 EDT
Lines: 74

In article <[e-mail]> [e-mail] (Ken Baer) writes:
>OK, first of all, I do realize that the Mac OS does not yet support real
>Multitasking (nor does MS Windows).

Careful, thousands of people are cringing right now over the flame war
you might have just touched off.  (Some people are so irresponsible.)

>But, I keep hearing about certain applications or inits that allow
>programs to run in the background (like the one that allows Think C
>to compile in the background).

It is pretty easy for an application to do.  In fact, it is so easy
that INITs have been known to convince certain applications to do it.
(To be honest, I am pretty sure Think C has always allowed some
background processing, it just kept the user tied up while this went
on.)

>What I want to do is allow our 3D rendering software to render in the
>background to the user can use the modeller etc. while rendering.
>Could someone either post, or point me to some documented code to set
>this up?

Look in Inside Macintosh Volume VI or the new "Processes" volume of
Inside Macintosh for details, but in general, there are two things to
do:

1) When your code gets CPU time (you will know this because it is
executing) do your thing.

2) When the user decides to say something to your running code--for
example canceling the rendering he mistakenly started--notice the
"Stop" menu choice, or "Cancel" button, or command-period keystroke,
and act on it (by stopping in this case).

Because this is a user-oriented machine which is valuable precisely
for its user interface, be very responsive about noticing that the
user is talking to you.  Don't make the user pound on the keyboard.
To notice that the user is talking, call GetNextEvent(), and act on
anything you hear.  (Or call WaitNextEvent() if you are just sitting
around waiting for something to happen.)

Oh, and don't do anyThink stupid like putting up a traditional modal dialog
box.  It will prevent the user from switching to another layer.  Use a
regular window or a newer movable modal dialog instead.

Simple.  You are done.  You have written a program which is responsive
to the user and it is happily multitasking.

Okay, this does mean that inside your tight loops you need to notice
the passage of time and occasionally check for user input.  (Do this
several times a second--and possibly be clever and calibrate this at
runtime based on how fast my Mac can run your loop.)  But what do you
expect of an 8-plus-year-old architecture which started out in 128K of
unprotected RAM??  Don't get greedy.

The secret: Everytime you call GetNextEvent() or WaitNextEvent() the
system potentially offers execute time to other applications.
Everytime the other applications call one of those routines you
potentially get execute time.  Coopertive multitasking does require
cooperation but it makes for a very user-responsive system when folks
do cooperate.  It is what Modern True Real Time Multitasking Operating
Systems very often do--honest.


Make Sense?  If not, say so and there will be lots of helpful advice
coming your way--but PLEASE avoid fighting words like "Real
Multitasking" in future postings.


--
Kent Borg                                   [e-mail] or [e-mail]
                                            H:[phone]  W:[phone]
As always, things look better when some costs are left out.
                              -Economist 3-28-92 p. 94