Rohit, I don't use IBO so I can't comment to much on that. BUT, are you worried about timers that IBO uses, threads that IBO uses, or threads and timers created in your own code?
I have big IBX apps which use both and run fine for years. If you have your own threads doing stuff, then those threads should NEVER use SetTimer. You can use SetWaitableTimer and learn about using Windows events to control your threads. IMHO it is always a good idea to create a stop event to give to a thread's constructor, and re-declare terminate to set that event. A few calls to WaitForMultipleObjects including both the waitableTimer and the stop event as things to wait on will nearly always solve the sync problems. Then you can call SetEvent(evStop) in whatever is controlling the thread. I have yet to find a safe way to call TThread.WaitFor. It almost always causes deadlocks or stack corruption. It is often more efficient to use the Interlocked....... API functions than to use critical sections (if you can re-structure your code to do this), and PostMessage is often more efficient when communicating with the main VCL thread than calling Synchronize. Make all of your TThreads FreeOnTerminate, and set the instance variable pointing to the TThread to nil in the destructor. procedure StopThread; begin SetEvent(MyThreadStop); while assigned(MyThread) do; end Something along those lines works well for me, even with hundreds of threads working with lots of remote databases...and not a crash or a freeze ever reported. Trevor ----- Original Message ----- From: "Rohit Gupta" <[EMAIL PROTECTED]> > Back to square 1. :-( > > We are having severe problems with our apps either freezing and > crashing a rather too regularly. It appears to be memory trashing. > We can replicate in a rather simplish app so we dont think we have > stuffed up... But everything and everybody's code is suspect.... > thats IBO, Borland and Windows. > > The frequency of error is proportional to number of threads, number > of memory allocations. Often it is so severe that the exception has > an exception and the stack is definitely trashed at this point. > _______________________________________________ Delphi mailing list [EMAIL PROTECTED] http://ns3.123.co.nz/mailman/listinfo/delphi
