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/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
