Re: Puzzling run loop/autorelease pool question
Re: Puzzling run loop/autorelease pool question
- Subject: Re: Puzzling run loop/autorelease pool question
- From: Michael Ash <email@hidden>
- Date: Sun, 5 Apr 2009 19:50:28 -0400
On Sun, Apr 5, 2009 at 5:11 PM, m <email@hidden> wrote:
> I'm having trouble with autoreleased objects not being released when I
> expect them to be released.
>
> I'm writing an app that observes ui elements of another app using the
> Accessibility API. I get a root ui element from the observed application and
> register for the kAXMainWindowChangedNotification.
>
> CFRunLoopAddSource([[NSRunLoop currentRunLoop] getCFRunLoop],
> AXObserverGetRunLoopSource(observer), kCFRunLoopDefaultMode);
>
>
> The idea is that when the observed application's main window changes, my
> observing app takes special action in response.
>
> So far so good. Here's the weird part: any autoreleased objects I allocate
> in my notification handler aren't in fact released until my observer app
> gets "tickled" by some event. So if my observer app is just sitting there in
> the background logging notifications to the console, any autoreleased
> objects created just pile up in the autorelease pool. Clicking in the
> observing app's window, or even just activating it then triggers a massive
> release festival.
>
> I suppose one explanation is that my run loop is stalled because it thinks
> there is nothing to process, but I can't find a straightforward way to
> programmatically tell the run loop to iterate. In any case, my understanding
> was that this was a detail I needn't worry about,
>
> A hack-around that seems to work: in my notification handler, I schedule a
> method for the next run loop iteration (using -[NSObject
> performSelector:withObject:afterDelay:]) in which I do all the real work,
> but I am puzzled as to why this works.
>
> It seems like there are lots of cases where one might write a background
> only app that doesn't receive events but whose autorelease pools are
> nevertheless drained at the end of a run loop iteration, which suggests that
> run loops really ought to keep iterating when necessary without any special
> action on the coder's part.
>
> Perhaps there is a subtlety of run loops that I'm missing. Can someone
> clarify this?
All you're missing is that runloops don't cycle the autorelease pool
for every single action. They do for most, but there are some they
miss. C-like callbacks such as this one tend to be in the "miss"
category. The pool still *exists*, so you don't really leak, but it
doesn't get drained until something happens that actually triggers the
pool, as you saw.
The workaround is easy. What you're doing is fine, or you can post a
fake NSEvent, or something similar. Pretty much up to you.
If you're interested, more details here:
http://www.mikeash.com/?page=pyblog/more-fun-with-autorelease.html
Mike
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden