• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Puzzling run loop/autorelease pool question
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Puzzling run loop/autorelease pool question


  • Subject: Puzzling run loop/autorelease pool question
  • From: m <email@hidden>
  • Date: Sun, 5 Apr 2009 14:11:35 -0700

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?

_murat

_______________________________________________

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


  • Follow-Ups:
    • Re: Puzzling run loop/autorelease pool question
      • From: Michael Ash <email@hidden>
    • Re: Puzzling run loop/autorelease pool question
      • From: m <email@hidden>
  • Prev by Date: Re: NSString and decoding HTML Entities
  • Next by Date: Re: NSString and decoding HTML Entities
  • Previous by thread: Re: crash reading archive
  • Next by thread: Re: Puzzling run loop/autorelease pool question
  • Index(es):
    • Date
    • Thread