RE: Apple Events and automatic AutoReleasePool managment
RE: Apple Events and automatic AutoReleasePool managment
- Subject: RE: Apple Events and automatic AutoReleasePool managment
- From: Andy Klepack <email@hidden>
- Date: Mon, 17 Mar 2008 14:25:14 -0700
- Acceptlanguage: en-US
- Thread-topic: Apple Events and automatic AutoReleasePool managment
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@hidden]
Sent: Monday, March 17, 2008 12:35 PM
To: Andy Klepack
Cc: email@hidden
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 (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