Re: Apple Events and automatic AutoReleasePool managment

FROM : Jens Alfke
DATE : Mon Mar 17 20:34:42 2008

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