Re: Unconventional memory leak problem
Re: Unconventional memory leak problem
- Subject: Re: Unconventional memory leak problem
- From: Erik Buck <email@hidden>
- Date: Wed, 6 Sep 2006 07:40:41 -0700 (PDT)
As you already know but I will state for posterity,
Drawing from threads other than the main thread is not well supported by AppKit.
Further,
When drawing from the main thread, it is a good idea to keep the AppKit's event loop running and use -setNeedsDisplay: or a variant instead of straight -display.
In normal interactive applications, keeping the event loop running is a non-issue.
In multi-threaded applications with heavy worker threads, there can be an issue.
Some ways to keep the AppKit's event loop running is to schedule a timer or use -performSelector:withObject:afterDelay:. Another way is to use distributed objects and/or NSPort. http://developer.apple.com/documentation/Cocoa/Reference/Foundation/Classes/NSPort_Class/Reference/Reference.html
The main thread of an AppKit based program normally blocks waiting for input from one or more input sources such as the window server which provides mouse, keyboard, and a few other events as input. Timers are another input source. An NSPort can be setup as yet another input source. When data is available via the port, the main thread will unblock to process the data. The port can then be used for inter-thread communications.
My supposition about your symptom is that drawing via -performSelectorOnMainThread: does in fact produce some objects that are in one of the main threads autorelease pools. No subsequent event (input) is available to wake up the main thread so the main thread remains blocked and doesn't release the autorelease pools.
Using a port (and perhaps distributed objects) explicitly may work better than -performSelectorOnMainThread:. Scheduling a repeating timer may be the easiest and simplest way to provide input that will un-block the main thread.
Finally, I will repeat my frequent rant that multi-threaded programming is worse than useless in most applications. If there is a need to use multiple processors or a task is naturally very parallel, use multiple processes as opposed to multiple threads. The only important difference between processes and threads are that processes have memory protection and threads dont. The memory protection exists to save you much hassle. Use it.
In your application, it seems likely that you could implement a display server that communicates via sockets, message queues, pipes, or distributed objects with one or more worker processes that gather data to be displayed. When implemented as separate processes, you will find it easier to program, easier to debug, and easier to control by users who can for example change the nice levels to suit their needs. Best of all, when a process dies (naturally or on purpose), the operating system take care of all the needed clean-up.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden