On Mar 13, 2007, at 7:59 AM, Stephen Dodd wrote: > 1) Is it wise to allow a thread to escape its class? > For instance, myThreadClass might call other classes (which may call > other classes) and wander around the code a little before coming > back. I've pre-cautionary protected all diskIO methods with > CriticalSection.
This is perfectly reasonable. Calling any method of any object from within the Run event handler just means that it will execute in the thread represented by the object. > > 2) If a thread is suspended and the main app thread/loop calls > myThreadClass.MyMethod, will your code pause until (hopefully) the > thread is resumed? This you should test to determine. > > 3) If you can't base your class on Thread, is it OK to instantiate a > thread class and then call yourself? > For instance myIneritedClass creates MyThreadClass (stored as a > property) which immediately calls myInheritedClass.DoYourThing Yes. > > 4) Should threads be "closed"? > Is it OK to allow a thread to just run out of code? Should it be > specifically killed? Is it gracefully killed when the object has no > references and gets eventually garbage collected? > Yes. Charles Yeomans _______________________________________________ Unsubscribe or switch delivery mode: <http://www.realsoftware.com/support/listmanager/> Search the archives: <http://support.realsoftware.com/listarchives/lists.html>
