Background TCL
Volume Number: 9
Issue Number: 12
Column Tag: TCL Workshop
A Piece of Apple π 
Background processing with TCL
By Malcolm H. Teas, Rye, New Hampshire
Note: Source code files accompanying article are located on MacTech CD-ROM orsource code disks.
About the author
Malcolm Teas has been programming the Macintosh for five years. He’s active
with object programming in TCL and also uses C with Think and MPW. He lives,
works, and consults from his house on the seacoast of New Hampshire.
I needed a project to test the new Think C version, since I have an interest in
number theory, the project I picked was a π calculation program. Most similar
programs take over the machine while they’re at work. I wanted this one (just to keep
life interesting) to optionally calculate π in the background and let other applications
continue. As the Mac doesn’t have preemptive multitasking, background applications
only get time as permitted from the foreground application and vice versa. So, when
we program time-intensive tasks, we’ve got to be nice to other software that may be
running. The approach I took here is to let the user decide if this application should
hog the system or not by setting an option in a menu. The default is to not hog.
To do this, I break the calculation up into a number of steps. The steps are
implemented by a subclass of a TCL Chore object. This work is done at idle event time
indirectly by the Dawdle() method of the bureaurocrats. The amount of CPU time that
the calculation takes is the same if it’s done in the background or if the application
hogs the system. However, the amount of time to the user is significantly longer if the
work’s done in the background. This is due to the overhead of the time through the
toolbox getting the idle event to run the calculation code. In addition, the calculation
code is done in small steps and interspersed with other applications, etc. In the hog
mode, it never leaves the calculation code at all but other apps don’t get CPU time.
Backgrounding is best for an application that’s got pre-calculation to do or can
intersperse work with user input. As humans are so slow compared to the computer,
the imbalance of speed can be put to good use this way.
Designing a chore for background processing
There are a couple of issues for chore-based background work. First, the chore
has to be handled or know where to get all the information it needs for it’s processing.
Second, if it’s work that gets completed that something else depends on, the chore has to
be able to signal work complete. Last, chores need to be disposed of. One thing at a
time.
In my case, my CPiChore class is a subclass of the CChore class. You’ll have to
subclass the CChore class too as the standard class does nothing. The only method in
CChore is the Perform() method (and of course those methods it inherits from
CObject). My CPiChore subclass overrides the Perform() and Dispose() methods. It
also has two new methods InitChore() and GetTicks() for setting the necessary data and
getting information.
The InitChore() method takes all the necessary data as parameters. If I’d had a
lot of data I could’ve passed a structure with the data loaded into it. However, as I only
had four items, that seemed overkill for this project. Another alternative would’ve
been for the chore to ask the necessary objects for the relevant data.
InitChore() takes the number of digits of π to calculate, a pointer to the
document object, and two flags to determine if the calculation should be timed and if hog
mode is on. This data is stored locally. Note that the flags are stored in the object, but
the document and the number of digits are stored in global variables that are defined
and declared in the CPiChore.cp file. This makes them local to that file. The document
object CAppPiDoc declares the CPiChore in it’s include file (CAppPiDoc.h). As a
short-cut, I included the CAppPiDoc.h file in the CPiChore.cp file, and declared a global
“document”. This means that I don’t have to type-cast as often when I use the
“document” variable. The “Digits” variable is where the numDigits value is put. As
this π calculation code is ported, I didn’t convert all the calculation code to methods,
instead, I left them and their global data in this CPiChore.cp file as straight C functions
and data.
Perform() is the function in a chore that actually does the work. It’s called by
the Idle() function in CApplication which is called every time an idle event happens.
TCL considers an idle event to occur when we either receive a null event or a
mouse-moved event. Note that if you’re doing background processing, you want null
events while you’re app is in the background. To get them, the “Background null
events” flag in the Size resource must be set. Use the SIZE flags popup in the Set
Project Type dialog to do this.
The Idle() function also does some other things like check memory and do the
Dawdle() method in the CBureaucrat object. Idle() runs through the chain of command
to call all the Dawdle() methods there. It then runs through the list of chores to call
Perform() on all the chores in the list.
When it gets to the Perform() method in CPiChore, CPiChore uses a stage counter
to figure out what’s been done and what to do next. Basically, this determines and
remembers what step it’s on. CPiChore uses the Machin algorithm to calculate π (see
the sidebar). The last step in the calculation stops the count of the time and tells the
CAppPiDoc object that the chore is done by calling PiDone() in the document with the
result of the calculation as it’s parameter.
The document gets the time the calculation took, sets flags for the state of the
calculation and sends the result to the pane for display. The next time and idle event
happens and the document’s Dawdle() method is called, the chore will be disposed of.
This approach to deallocating the chore is known as lazy management of memory. It has
the advantage that, as the Dawdle() method is called all the time, it’s more sure in
deallocating the chore. The completion and the deallocation are in independent routines.
The pane to display this information isn’t a standard text edit pane. Text edit can
only handle information up to around 30K of text characters. It’s easy to generate a
value of π that takes more space that this. I subclassed CPanorama to make a pane that
just displayed a lot of text for this application. In addition, this CPiPane object also
knows how to translate the digit numbers to text characters and how to display the time
information too.
Implementation details
All the key user actions are handled through the DoCommand() method of the
CAppPiDoc object. The one exception is the about box which is handled in the
application’s DoCommand() method.
The number of digits is set in a dialog box that I use the regular TCL dialog classes
to run. The DoCommand() method extracts the digit count from the dialog before it’s
disposed. Although Symantec’s documentation states that the dialog objects must be
subclassed to be really useful, I didn’t find the need to do that with the number of dialog
view objects that know about the format and range of information. In this case, I used
an integer text dialog view object that was told, via the template, what range of
numbers to accept. Then, I use the FindViewByID() method to get that object and
extract the now-conditioned value.
The time and hog (or “faster”) commands just toggle their values. In the
UpdateMenus() method, these values are used to determine if those menu items are
checked or not.
The start command is the important one. If the π calculation chore is running,
then this item is labeled “Stop”. If selected, it cancels and disposes of the chore. If the
chore isn’t running, it starts it using the currently set number of digits and the timing
and faster flags. It then assigns the chore to the application, this puts the chore in the
chore list to be processed on an idle event. The chore will stay in the list until
removed.
Once the chore is in the list, then the Perform() method is called with every idle
event. If the faster or hog mode is on, then the Perform() method doesn’t return until
the calculation is complete. Otherwise, it does one step and returns.
When the calculation is complete, the Perform() method calls the PiDone()
method in the document which hands the result data off to the pane for display with the
pane’s SetContent() method. This result data looks like the other data used in the
calculation. It’s an array of character, but I use the characters as small integers.
Actually, there’s a fair amount of wasted space as the integers range from 0-9. The
calculation is carried out in decimal and there are custom routines to handle multiple
place arithmetic.
The SetContent() method disposes any previous pointer to data (the data is held as
pointers due to the ported code) and converts the data to characters for display. It does
this by simply adding the integer value of the character zero to each number in the
array.
When the Draw() method for the pane is called (it’s called automatically when
the pane needs to be refreshed or when Refresh() is called), it sets the font and size of
the text to draw. Draw() then creates a header line, draws it, skips down a little and
draws the characters for π. To do the drawing of the text, Draw() calls a routine
called DrawWrapText() to wrap the text at the margins correctly.
DrawWrapText() takes parameters to the text, it’s size, and the margin, line
information and whether or not to force a margin. This latter is similar to typing the
return key to force a new line.