Looking at the Time Profiler instrument in Instruments, it looks like I’m not disposing of threads after I’ve used them. The list of “All threads” grows as I do operations that start a thread.
I start my thread as follows (“thread” is local to the function):
UIApplication.SharedApplication.NetworkActivityIndicatorVisible = true;
Thread thread = new Thread(Dispatch);
thread.Start();
The Dispatch() function is:
private void Dispatch()
{
using (NSAutoreleasePool autoreleasePool = new NSAutoreleasePool())
{
try
{
// Calls a web service.
_workDispatcher.Dispatch();
}
finally
{
// Resets network activity indicator after thread complete.
InvokeOnMainThread(() => { UIApplication.SharedApplication.NetworkActivityIndicatorVisible = false; });
}
}
}
_workerDispatcher.Dispatch makes a call to a web service.
What more should I be doing to destroy the thread on completion?
The application crashes after an extended period of time – and we’re guessing it might be threads – as it launches them regularly to conduct shortish operations. I’ve read that monitoring memory usage in MonoTouch is a challenge due to garbage collection – or I’d see if memory was also being consumed (e.g. by threads remaining).
I’m using MonoTouch 3.2.5 and iOS 4.3.1 (and Instruments in Xcode 4). App needs to work on iOS 3.x, so I can’t use Grand Central Dispatch.
It looks like this was a garbage collection issue. If I put a call to GC.Collect() after the thread completes, the number of threads doesn’t appear to keep growing.