November 93 - BAMADA Notes
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.
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.