Thanks Jens, that's some really useful information. In the case of C callbacks wouldn't it be the case that an autorelease pool would exist (that of the main thread) but that it would not be emptied once the callback completes? You wouldn't see any warnings if that were the case. Essentially any objects autoreleased in the callback would be placed in that pool, but since the callback exits without somehow making it known that the pool should empty the app's memory footprint grows until something prompts the empty to occur.
I'm seeing this problem in some AE handlers installed via AEInstallEventHandler. There are no warnings about a pool not existing, but the app memory usage grows and grows. Wrapping the handler in a pool creation and release appears to solve this. -Andy -----Original Message----- From: Jens Alfke [mailto:[EMAIL PROTECTED] Sent: Monday, March 17, 2008 12:35 PM To: Andy Klepack Cc: cocoa-dev@lists.apple.com Subject: Re: Apple Events and automatic AutoReleasePool managment On 17 Mar '08, at 11:38 AM, Andy Klepack wrote: > Does an 'event cycle' then include anything dispatched from a run > loop source? For instance, if I was to create a kqueue, create a run > loop source for it, and add that to the main run loop, does an > AutoReleasePool automatically get created before the handler is > called and destroyed after it returns? In general, Objective-C callback methods are invoked with an autorelease pool in place. There are exceptions, though (the code that runs in a new NSThread is one example). But C callbacks invoked from CoreFoundation or lower levels won't have autorelease pools. So your kqueue callback needs to create its own autorelease pool, because it's a C callback called from CoreFoundation (CFRunloop). > What about for invocations that result from DO communication in > which the incoming port is registered on the main run loop? DO puts an autorelease pool on the stack before it calls into your objects. It's not that critical to make the right decision here immediately, though. If you leave out an autorelease pool where one is needed, you'll get lots of console warnings telling you so, and you can go back and put one in. If you put in an autorelease pool where it isn't needed, it's a tiny performance hit but won't hurt anything. What's more important is to wrap all C callbacks in an @try block to catch all exceptions. Throwing an exception out of your callback past exception-unaware C code is practically guaranteed to mangle system state and cause hard-to-debug crashes soon thereafter. It's also important to catch exceptions in the top-level method of a thread, since an uncaught exception without any handler on the stack will cause your whole process to abort. -Jens _______________________________________________ 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 [EMAIL PROTECTED]
