Thread safety

[Edward K. C. <ek...@lg...>]

I am currently Carbonizing an old Quickdraw 3D app which did a lot of 
iterative updating out of the main event loop.  I want to move most of 
this logic into an MPTask, but am worried about the thread safety of 
the Quesa APIs.

My approach so far has been to do geometry manipulations in the thread 
and then signal the main process to handle the rendering.  Being 
paranoid, I defined a single global critical region across the entire 
application to wrap around every set of calls to Quesa functions.  
Depending on the locality of data in the library, I might have been 
able to get away with separate regions for each document (which has its 
own unique 3D view, thread, and geometries), but I didn't want to take 
any chances unless this is deemed safe.  Nevertheless, I have seen some 
impressive results already.  Activity Monitor says my app running on a 
dual processor G4 is sometimes using as much as 130% CPU, which 
suggests that it is rendering and calculating for the next iteration at 
the same time.  Whatever the case, it is running much faster than it 
used to.

One concern I have is over memory allocation.  Does Quesa use NewPtr() 
to allocate retained-mode objects?  That could be a problem, because I 
suspect it is not safe even in Panther.  malloc() is something of a 
mixed bag.  Apparently, it is safe in the gcc libraries, but under 
CodeWarrior, it calls NewPtr() by default (as of CW8.3).  :-(  You need 
to set the _MSL_THREADSAFE flag in ansi_prefix.mac.h and rebuild all 
the libraries to get it to use MPAllocateAligned() instead.

-Ted