Re: release not done right away
Re: release not done right away
- Subject: Re: release not done right away
- From: Nicolas Berloquin <email@hidden>
- Date: Wed, 21 Apr 2004 13:28:16 +0200
I'm using one timer for each peer that I need to prune. what happens is
this :
(all in the main runloop btw) :
at some point the NBPeer sees that the connexion is closed/dead. From
the
chain of events that leads to this info, It can't [self release]
itself, so a timer is setup
to kill it after 2 seconds (from the selector of another object,
actually the object
that holds the array of NBPeers), like "prune me, I'm dead anyway".
For the sake of simplicity, I'm using a newly allocated NSTimer inside
the very (dying)
peer, knowing that it will be autoreleased later on (no accounting
necessary).
But there is a second type of situations when my NBPeers are declared
dead, ie
I have a second set of timers that fire after 180 seconds of
inactivity. This timer
will in turn call the same instance methods and therefore create the 2
second NSTimer.
What I'm wondering now is where to start/end an autorelease pool for
the second type of timers ?
You see, this part of the app is completely timer driven. No event loop
(why should I need one ?
(it will become necessary only if there is no other way to manage the
autoreleases)).
Using timers this way makes it very simple for me to handle everything.
Why is it strange? This is a valid optimization- if the app doesn't
need to do anything, it doesn't. Why are you using more than one
NSTimer?
this is strange (in my opinion), because RAM isn't infinite, and
neither is swap space. what if
all this ends up taking gigabytes of memory ? This would make the
user's mac crawl when
simple autorelease GC would have prevented it.
On 21 avr. 04, at 13:12, A.M. wrote:
On Apr 21, 2004, at 1:05 PM, Nicolas Berloquin wrote:
ok I found what I believe is the guilty instance.
I'm using an NSTimer to prune my NBPeer after a couple seconds.
The NBPeer is inside the userInfo of the timer. And the Timer is an
autoreleased
object... which holds onto it until the main loop's pool autoreleases
it...
So I'll have to put all those timers inside my own pool that I cleaup
when I need to.
strange though that minutes or hours can pass before the main pool
gets emptied
(when the app is not in front or hidden).
Why is it strange? This is a valid optimization- if the app doesn't
need to do anything, it doesn't. Why are you using more than one
NSTimer?
,,,,,,,,,,,,,,,,,,,,,,,,,,,
AgentM
email@hidden
,,,,,,,,,,,,,,,,,,,,,,,,,,,
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.