Sprocket Threads
Volume Number: 10
Issue Number: 12
Column Tag: Enhancing Sprocket
Adding Threads To Sprocket 
Programming like you had a “real” OS
By Steve Sisak, Articulate Systems
Note: Source code files accompanying article are located on MacTech CD-ROM orsource code disks.
About the Author
Steve Sisak - Steve lives in Cambridge, MA, with three Macintoshes, two
Newtons, and two neurotic cats. He referees Lacrosse games, plays hockey, drinks
beer, and searches for the perfect vindaloo. He also finds time to work on a speech
recognition system for Articulate Systems during the day, a multithreaded
communication server and thread-savvy studio library at night, and a variety of odd
jobs the rest of the time.
Last month, in Randy Thelan’s article “Threading Your Apps”, you learned a bit
about the theory behind the Threads Manager and how to call its routines. This month,
we’ll skip past the theory and focus on how you can combine the Threads Manager and
the AppleEvent Manager, with the help of a couple of small libraries, to make the job
of writing a modern Macintosh application much easier. Rather than cover every
aspect of the Threads Manager, we will concentrate on a few key features that can
really save you time. In fact, if you’re using the libraries as-is, you may never need
to call the Threads Manager directly at all. The libraries, AEThreads and Futures, are
useful as both stand-alone libraries and as non-trivial examples of multi-threaded
code. In addition, in what I hope continues as a good trend, I have integrated them into
the MacTech application framework, Sprocket. We’ll start with a quick overview of
the libraries, continue with a description of how to use them, and finally delve into the
details of how they’re implemented. Even if you only plan to use the libraries as-is,
this section should help you to understand threaded programming and may also help you
avoid traps and pitfalls I’ve already encountered.
The application model we’ll be using is a threaded extension of the fully factored
application that Apple has been begging us to implement for the last few years - it is
split into a user interface portion and a server portion which communicate with each
other using AppleEvents. The difference is that, instead of handling each event
sequentially, the AEThreads library allows the server portion of the application to
handle multiple events con currently and asynchronously, each in a separate thread of
execution. It takes care of all of the bookkeeping involved with spawning and cleaning
up after the threads, suspending and resuming the AppleEvents, and reporting errors
to the AppleEvent Manager. Further, the Futures library provides routines that allow
you to write client code in a traditional linear style, without idle procs, and to ask
multiple questions of multiple servers simultaneously. And, even better, the Threads
and AppleEvent managers do all of the hard work for you!
I first got interested in threaded AppleEvent code while working on a credit card
validation server (Credit Now!, Appropriate Solutions). The intent was to develop a
small application which could receive information about a purchase, dial up the credit
card network, process the transaction and return an authorization code. Sending an
AppleEvent seemed like the logical thing to do. The problem was that, with the phone
Referenced by (1):