November 93 - BAMADA Notes
BAMADA Notes
Robert Lenoil
The October BAMADA meeting featured Eric Anderson, author of Apple's Thread
Manager package, and Bo Klintberg, author of Software Framework Association's
soon-to-be-released OSL Scripting Components product. (There was a September
meeting, but I unfortunately couldn't attend, and therefore can't report on the
proceedings.)
The Thread Manager is a Macintosh system extension that provides for multiple
threads of execution within a single application. Multi-threaded is all the rage
nowadays: Windows NT does it; OS/2 has been doing it; and like so many other "new
features in desktop computer operating systems, many flavors of UNIX have been doing
it for years. Now, thanks to the efforts of Eric Anderson and company, you can use the
threads model of programming on the Macintosh too.
A thread is a lightweight task within a process that shares all the process's resources
(open files, address space, etc.). Basically, a thread is just a private stack and a saved
program counter and registers. As context switches go, switching between two threads
is fast. When you have a time consuming task to perform or are doing polled or
asynchronous i/o, create a separate thread to perform the activity. Periodically or
while waiting for i/o, your thread sleeps to allow other threads to run; this lets your
program maintain a responsive user interface without the tedious effort of state
machine-based background processing from the main event loop, à la MacApp
cohandlers or similar mechanisms.
Version 1.2 of Thread Manager is on Apple's November Developer CD. It is not the
thread manager described in issue 6 of Apple's d e v e l o p magazine (that thread
manager was unsupported and is now obsolete) but the concepts discussed in that
article do apply. It can be shipped with your commercial programs for a nominal
licensing fee. Also on the developer CD is Voodoo Monkey, a threads-aware debugger
(the Debugger from Jasik Designs also knows about Thread Manager); and a utility
package that adds semaphores and other features built on top of the basic Thread
Manager API.
Thread Manager supports two styles of thread: cooperative and preemptive.
Cooperative threads are scheduled at WaitNextEvent time. The default scheduler calls
all runnable cooperative threads in a round robin fashion, with special provision for
activating the main thread (the initial thread, which will handle your main event
loop) whenever an event is available in the OS event queue. Preemptive threads are
preemptively multitasked, which means that they run until they yield to another
thread or until their time quantum expires. Preemptive threads must follow the rules
for code that executes at interrupt time, namely, they cannot call any trap that can
cause memory to be moved and they must not call traps where reentrancy is a concern.
Preemptive threads are ideal for porting bulky number crunching algorithms to the
Macintosh; without any coding changes the main thread will still get processor time
and allow the user interface to operate while the computation occurs in the
background. Tom Becker demonstrated this technique to the audience with a
thread-based version of FracApp, a program which computes and displays the
Mandelbrot set.
Threads Manager does have some limitations. For starters, it is only available for
applications; not for desk accessories, INITs, or drivers. Thread switching only occurs
when the target application is given time by the Process Manager. Since the Process
Manager uses a cooperative multiprocessing model, threads - even preemptive ones -
can be kept waiting for indefinite periods of time by unfriendly foreground
applications. Last, but not least, Eric Anderson announced that preemptive threads will
not be supported for native mode applications on PowerPC Macintoshes. So unless you
plan on running your applications on PowerPC only in 680x0 emulation mode, you
should not use preemptive threads.
OSL Scripting Components
Bo Klintberg spoke to the BAMADA audience as part of his US tour of MADA affiliates.
Bo hails from Sweden, where he is hard at work putting the finishing touches on his
AppleEvent/AppleScript support library for MacApp. The package is very complete,
with a format modeled after MacApp's. It comes with source code (C++), sample apps,
an introductory guide, cookbook, class and method reference, 411 help files, and an
OSL Scripting Suite reference. The documentation comes to over three hundred pages.
Unlike Ken Ryall's MAScript package, which modifies the MacApp source code to add
AppleEvent support to existing MacApp classes, OSL Scripting Components leaves the
MacApp code untouched and provides a whole new set of classes for dealing with
AppleEvents. There are separate classes for client events (which send requests) and
server events (which respond to requests). To support a new AppleEvent, your
subclass must override the PrepareMessage and ReplyComplete methods; most of the
other work is handled for you.
OSL Scripting Components will come with demo applications for an AppleEvent client,
an AppleEvent server, and an AppleScript recordable application. In the future, Bo
would like to add handlers for the AppleEvent table and database suites. Personally, I
wanted him to hurry up and get back to Sweden so that we could get this package
sooner; it looks like a winner for AppleEvent and AppleScript programming in
MacApp. Hopefully by the time you read this Software Frameworks Association will
have announced availability and pricing.
Next time
BAMADA meets the first Thursday of each month at 7pm at 4 Infinite Loop in Apple's
R&D campus in Cupertino. At the November meeting, members of Apple's MacApp team
will discuss the upcoming 3.1 release. Also, Tom Becker will be giving a
demonstrations on drag and drop, and show a new class that does it for you with no code
additions. If you're interested in speaking at an upcoming meeting, or want to be placed
on the mailing list for BAMADA announcements, contact Eric Hanig or Tom Becker at
ABI.FC (AppleLink), Eric_Hanig@apldbio.com (Internet), or call 800-874-9869
extension 8902.