Managing multiple threads

It is extremely important that you understand concurrency management before introducing manual control of multiple threads. Working outside the View System's single-threaded concurrency model introduces the potential for deadlock and race conditions, which can bring the entire system (not just your code) to a halt.

There are certain guidelines and considerations you must keep in mind when working outside the single-threaded model:

• Avoid using pointers to views in another thread unless you have total control over both threads. Create overrides or additional interfaces to implement the concurrency contract between a view and the other thread. If you call a view's member functions directly (that is, without using requests) from another thread, your implementation must manage the concurrency issues. This is particularly important when you allow a view to hold a pointer to another view, such as its parent in the view hierarchy.
• Override the HandleSetPort function in any view that interacts with more than one thread so that it stops any asynchronous drawing when the GrafPort becomes NIL.
• Implement a protocol for sharing input event information. Input events are handled in the view's thread. You have to determine how to propagate their effects, if necessary, to other threads that use the view.