Hi Guys, thanks for the detailed responses :)
Peter, thanks for that example, I should have thought of doing a
similar test myself, but I didn't, so thanks for doing that, always
the best way to be sure ;)
Michael, so does this mean that CFRunLoopTimer and NSTimer don't
behave the same way? I always assumed 'toll-free bridged' meant that
you could use them interchangeably, the NSxxx were just Cocoa wrappers
for the CF stuff, but it seems behavior is not the same...
And just to re-iterate, I do not need to create an autorelease pool
around my timerFired callback, it will get drained at the end of every
run...
Cheers,
Memo.
On 26 Feb 2009, at 04:50, Michael Ash wrote:
On Wed, Feb 25, 2009 at 8:45 PM, Peter N Lewis
<pe...@stairways.com.au> wrote:
OK, I will certainly defer to Michael's deeper knowledge on this
stuff,
Oh no, don't do that....
but
I thought Leopard plugged most of the normal case holes for
requiring an
auto release pool, so I wrote up this test case:
#import "AppDelegate.h"
@interface BogusObject : NSObject {
}
@end
@implementation BogusObject
- (id) init;
{
self = [super init];
if (self != nil) {
NSLog( @"BogusObject init" );
}
return self;
}
- (void) dealloc;
{
NSLog( @"BogusObject dealloc" );
[super dealloc];
}
@end
@implementation AppDelegate
- (void) timerFired:(NSTimer*)theTimer;
{
NSLog( @"timerFired" );
[[[BogusObject alloc] init] autorelease];
}
- (void) applicationDidFinishLaunching:(NSNotification
*)aNotification;
{
NSLog( @"applicationDidFinishLaunching" );
[NSTimer scheduledTimerWithTimeInterval:1 target:self
selector:@selector(timerFired:) userInfo:nil repeats:YES];
}
@end
With the app sitting in the background doing nothing, I get the
same results
whether timerFired uses "release" or "autorelease", ie every second
all
three messages are printed:
2009-02-26 10:38:43.440 CheckTimer[82997:10b] timerFired
2009-02-26 10:38:43.441 CheckTimer[82997:10b] BogusObject init
2009-02-26 10:38:43.441 CheckTimer[82997:10b] BogusObject dealloc
For good measure, I tried this on Tiger, and got the same results,
so now
I'm just left wondering where my confusion lies.
Well, obviously NSTimers *don't* suffer from this problem, and didn't
on Tiger either, and perhaps not ever. Clearly I was mistaken there!
You can reproduce the behavior I described if you use a CFRunLoopTimer
instead of an NSTimer. Replace your AppDelegate code with this:
static void Callback(CFRunLoopTimerRef timer, void *info)
{
NSLog( @"test fired" );
[[[BogusObject alloc] init] autorelease];
}
- (void) applicationDidFinishLaunching:(NSNotification
*)aNotification;
{
NSLog( @"applicationDidFinishLaunching" );
CFRunLoopTimerRef timer = CFRunLoopTimerCreate(NULL, 0, 1, 0, 0,
Callback, NULL);
CFRunLoopAddTimer(CFRunLoopGetCurrent(), timer,
kCFRunLoopCommonModes);
CFRelease(timer);
}
As long as the app sits idle, you'll see only allocation. Once you
push an event to it, for example by clicking the mouse, all the queued
up objects get destroyed.
So it can indeed happen relatively easily as I described, but clearly
I was confused as to where it can happen, and the OP will have
absolutely no trouble with his code and doesn't need to make his own
pools.
Mike
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/memo%40memo.tv
This email sent to m...@memo.tv
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
