Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!uwm.edu!ux1.cso.uiuc.edu!pequod.cso.uiuc.edu!dorner
From: dorner@pequod.cso.uiuc.edu (Steve Dorner)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Putting a computational task in the background...
Message-ID: <1991Apr8.172849.6908@ux1.cso.uiuc.edu>
Date: 8 Apr 91 17:28:49 GMT
References: <1991Apr8.162302.11597@cs.cornell.edu>
Sender: usenet@ux1.cso.uiuc.edu (News)
Organization: University of Illinois at U-C
Lines: 30

In article <1991Apr8.162302.11597@cs.cornell.edu> wayner@CS.Cornell.EDU (Peter Wayner) writes:
>I have a program that does plenty of disk-access and computation.
>I would like it to run in the background. I tried putting in 
>a few random "WaitNextEvent" calls in the proper location, but
>this didn't seem to be enough.

It kinda depends.  You may not be calling WNE often enough, and the tick
parameter may have nothing to do with it.  Try to figure out exactly what
parts of your program are being piggy, and work on them first.

>Any pointers on determining the 
>amount of "Ticks" to put in the parameter?

There was once a 'load average' program for the mac; what it timed was how
long it took a WNE call to actually return.  The longer the WNE took to come
back, the "busier" the mac was.

I've used this idea; when I'm giving time to other apps, I compare the
number of ticks the WNE took to complete with the number of ticks I asked
for.  If WNE took more time than I asked, I assume the mac is busy and
allow more ticks the next time.  If WNE returns 'on the dot' tickwise,
then I shave a few ticks off the next call.

This seems to work reasonably well.  How a bunch of apps all using this
technique would act as an aggregrate I don't know.  They might wind
up endlessly cycling their tick parameters and being in general foolish,
or things might settle down nicely.
--
Steve Dorner, U of Illinois Computing Services Office
Internet: s-dorner@uiuc.edu  UUCP: uunet!uiucuxc!uiuc.edu!s-dorner