Re: Strange memory leak with AsyncSocket and multithreading
Re: Strange memory leak with AsyncSocket and multithreading
- Subject: Re: Strange memory leak with AsyncSocket and multithreading
- From: Martin Redington <email@hidden>
- Date: Fri, 11 Aug 2006 05:55:45 +0100
On 10 Aug 2006, at 20:29, AgentM wrote:
The leak makes sense because the runloop will want a few additional
iterations to actually perform on the selector. When you exit, the
run loop will still have sources to service. Instead, wait until
the runloop is out of sources (remove any necessary sources) and
then simply return from the method.
-M
On Aug 10, 2006, at 14:59 , Martin Redington wrote:
I tried calling
[NSThread performSelector:@selector(exit) withObject:nil afterDelay:
10.0];
from the disconnection callback instead to get around this, and
indeed my AsyncSocket's no longer leak (according to OmniObjectMeter)
however, I do seem to have a new leak (variously an NSString,
NSArray, or one of my own classes, according to 'leaks').
The stack includes my disconnect method, and -[NSObject
(NSDelayedPerforming) performSelector:withObject:afterDelay],
and the number of leaks seems to co-incide with the number of times I
called
[NSThread performSelector:@selector(exit) withObject:nil afterDelay:
10.0];
I'm still playing with trying to remove the sources, but I note
Dustin Voss's comment at
http://www.cocoadev.com/index.pl?RunLoop
"The documentation says a run-loop will exit when all input sources
have been removed. Good luck getting that to happen."
Is the "leaks" output to be taken seriously? Does anyone know why
what looks like a reliable leak would show up as different classes in
the leaks output?
_______________________________________________
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