*** ThreadKit Beta Release Notes ***

The ThreadKit is a complete toolkit for trying to make
multithreaded NeXTSTEP programming a little less arcane.
It will be released as a commercial product at a very
reasonable price when complete.  This beta version expires
September 31.

The ThreadKit consists of four classes, a category and a protocol:

* TKThreadLocking Protocol

  A protocol that defines locking syntax shared by all ThreadKit
  classes

* TKObject Class

  A subclass of Object that adds the common locking mechanism
  used by all ThreadKit classes.  A TKObject combines the
  behaviour of the Mach Kit NXRecursiveLock and NXConditionLock
  classes while adding non-blocking locking methods

* Object ( TKThreadLocking ) Category

  Extends the TKThreadLocking protocol to all every class in
  your application so that every class you use behaves as if it
  inherited from TKObject

* TKResource Class

  A subclass of TKObject that manages a pool of named resources,
  allowing your application to lock and unlock ANYTHING in a
  thread safe fashion, including non-threadsafe functions like
  "printf"

* TKApplication Class

  A subclass of Application that allows threads to access AppKit
  objects and methods with impunity

* TKThread Class

  A subclass of TKObject that provides a mechanism for spawning
  and controlling autonomous threads

---

Two simple examples included demonstrate ThreadKit use, more to
come...

---

Planned for 1.0

  -  Finalized API

  -  Better documentation, including an introduction to
     multi-threaded programming
  
  -  More examples

  -  Implementation of bright suggestions from the Internet
     community!

Changes in 0.92:

  -  Thread-safe alternative to usleep added to TKThread class

  -  Beta extended to Sept 31

Changes in 0.91:

  -  Proper .pkg installation process

  -  Beta extended to Aug 31

Changes in 0.9:

  -  WARNING: The size of most of the classes have changed.
     You might as well recompile everything (again)

  -  A bug in the Object category preventing more than one
     non-threadkit object from being locked at a time (sigh)
     has been fixed

  -  The locking semantics shared by all classes have been
     extended to support waiting for particular states

  -  The documentation has been significantly updated
  
  -  A mechanism for controlling the Obj-C runtime
     multithreading policy has been added to TKThread

Changes in 0.8:

  -  WARNING: The size of the TKObject class has changed.
     You might as well recompile everything :-)

  -  Suspending threads by locking them was forcing extended
     busy-waiting that brought the system to its knees as
     thread priorities were pushed through the roof (more fun
     to describe than experience).  Locks in the ThreadKit no
     longer busy-wait

Changes in 0.7:

  -  WARNING: The size of the TKThread class has changed, as
     has its superclass.  Any subclasses need to be recompiled

  -  Thread control mechanisms (for suspending, resuming,
     yielding and exiting threads) have been implemented in
     the TKThread class

  -  Implemented a protocol (ThreadLocking) that TKObject,
     TKApplication and the ThreadLocking Object category all
     conform to

  -  A lingering bug that sometimes caused problems with
     applications that created threads during "awakeFromNib"
     messages has been fixed (note that this was what caused
     occasional unpredictable behaviour in the SampleTest demo
     app)

  -  A mechanism for locking ALL threads to ensure integrity
     of REALLY dangerous actions (eg: dynamic linking of new
     classes) has been added to the TKThread class

Changes in 0.5:

  -  WARNING: The size of the TKApplication and TKObject
     classes has changed, any subclasses need to be recompiled
 
  -  WARNING: For consistency between the growing number of
     ThreadKit classes and a desire to avoid naming conflicts, all
     locking and unlocking methods have been renamed "threadLock"
     and "threadUnlock" respectively
 
  -  WARNING: For consistency with AppKit methods, the
     TKThread method "initFor:performing:" has been renamed
     "initFor:perform:"

  -  Trying to lock the appkit from the main thread is now
     harmless

  -  Added locking semantics to ALL objects through the
     Object(ThreadLocking) category

  -  Added named resource locking via the TKResource class
 
  -  The "tryThreadLock" method has been added to all classes
     in order to attempt locking with non-blocking semantics

Changes in 0.2:

  -  Class names changed to shorten names and prefix all
     ThreadKit classes with "TK"

  -  More robust error checking (now only the thread that locked
     the AppKit can unlock it!)

  -  Threads are discarded properly when finished
  
  -  Nested locking of TKApplication is now supported
 
  -  Real documentation written & included
  
  -  The Objective-C runtime is now made thread-safe only when
     more than one thread is running

  -  Changes to the "SortingInAction" example code to use the
     ThreadKit are supplied.  See
     ThreadKit/Samples/SortingInAction/README for details

  -  Beta period extended to July 31

Changes in 0.11:

  -  Now supplied in single-architecture as well as
     multi-architecture form for those running 3.0

---

Feel free to write with comments, suggestions, criticisms.  Whatever.

Blake Stone
219 Edgevalley Mews N.W.
Calgary, Alberta, Canada
T3A-5E5

bstone@acs.ucalgary.ca