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 14:13:39 +0200
On 21 avr. 04, at 13:47, A.M. wrote:
On Apr 21, 2004, at 1:28 PM, Nicolas Berloquin wrote:
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".
Just in case you haven't seen it, take a look at the socket FAQ:
http://www.developerweb.net/forum/viewtopic.php?t=21
Of course, I'm not sure how you are monitoring the servers.
that's exactly what I'm doing. Everytime I receive the data, I
reschedule the timer 180sec away.
When it fires, I kill the connexion myself.
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.
Having so many timers doesn't scale. You should instead use one 2
second timer and one 180 second timer and should call your NBPeer
objects to perform some operations such as -(BOOL)isAlive. Obviously,
you should have a dedicated controller object handling this logic.
Remember that the 180 sec timer fires very rarely (usually peers stay
connected, and I'd say about 10-20 of them fire every hour).
For the 2 sec timer, well it's about the same as the 180 ones.
Why doesn't it scale ? From my understanding there's a loop that only
fires timers when they are ripe, so that
must be quite "cheap", isn't it ?
What I'm wondering now is where to start/end an autorelease pool for
the second type of timers ?
There probably is not an appropriate place because your timers are
strewn across the entire application space. You could create a new
autorelease pool before every nstimer creation, but again, this will
not scale. NSTimers are meant to be used with event loops- it is, in
fact, an event loop that trigger the timers. You cannot have an
NSTimer, for example, that has better time granularity than the event
loop.
I understand the relationship with the event loop, but I don't
understand where the scale factor comes in ?
Does it take too much cpu ? memory ?
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.
Is this a GUI app? An event loop handles user input from the mouse and
keyboard and update the screen. If you don't need a GUI, then create a
"Standard Tool" from the XCode templates.
^_^ now, let's not get over-excited here ;-)
this IS a GUI app, it has lots of bells and whistles that show what is
going on underneath. It's all about downloads going
on during hours. So the user might look every so often at the general
advancement of their dloads. Or they might hide the app
for a while.
Oh, I'm sorry, I saw what triggered your reply. When I said no event
loop, I meant that I don't have my OWN
network event loop, there is of course cocoa's main event loop, but
besides this all my network interaction is
timer-driven.
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.
That's why programmers need to be intelligent and not
keyboard-monkeys. If a programmer autoreleases 2 Gigs of accumulating
objects, he's a lousy programmer and doesn't understand the tools
given to him. Cocoa doesn't prevent bad programming and can't guess
which objects are useful anymore automatically. Some languages can-
this is called garbage collection- this is nice except that the
programmer has zero idea when his object will be actually released- I
choose manual release over this because it gives me more control of my
application space.
am I the monkey ? ugh ugh ugh ?
ok, unless you get into the type of problems I'm running in, like
having a cocoa-created-autoreleased object that stick to one of your
instances...
As for objects not useful, I would believe that objects with a retain
count of 0 and tagged autoreleased would be thought of "not
useful anymore" enough to be released (at least every so often even if
the event loop is idle).
I have the feeling that you're getting mad at me (judging from your
language). I really appreciate your input and
I believe I have always been nice with you. Please correct me if I'm
wrong ^_^ (english is not my first language).
_______________________________________________
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.